commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: Is JXPath support Boolean?
Date Tue, 06 Feb 2007 14:48:22 GMT
Whatever works for you... although I'm not sure you
should have had to use a String.  I think as long as
you used "Boolean getCache()" that should work.

Anyway...
-Matt

--- maomaode <maomaode@gmail.com> wrote:

> Hi Matt,
> 
> I appreciate  your help.
> I have change the is*** to get***, seems this is the
> easiest way to work 
> around,
> and another benefit from get a string instead of
> boolean is that i can 
> define my own TRUE or FALSE.
> So, i think that's it.
> 
> Thanks,
> James.
> > --- maomaode <maomaode@gmail.com> wrote:
> >
> >   
> >> Hi Matt ,
> >>
> >> Thanks for reply.
> >>
> >> Yes, your alternative solutions definitely will
> >> work,
> >> But, I'm not sure it's a good idea to make the
> >> JXPath support Boolean? 
> >> or do we have a plan to support Boolean?
> >>
> >> And anther related question is that, do we have a
> >> plan to support new 
> >> features in JDK5, e.g Generics, Annotation etc.?
> >>
> >> Thanks,
> >> James.
> >>     
> >
> > Hello again, James.  Honestly, commons-JXPath is
> in
> > "maintenance mode."  I certainly don't claim to be
> an
> > expert on its code; I just happen to be a person
> who
> > is willing to give it some minimal attention in a
> kind
> > of stewardship role, because I have ties to Apache
> and
> > a vested interest in seeing the project release a
> 1.3
> > version.  As it stands, the code relies on
> standard
> > core API mechanisms for its knowledge of bean
> > properties and I'm not sure it would be a
> worthwhile
> > endeavor to augment that for e.g. recognizing
> Booleans
> > when the same limitations already apply across the
> > Java community (meaning that workarounds are or
> should
> > be well-known).  Beyond this, wrt supporting new
> Java
> > features, and even supporting big-B-Booleans, for
> that
> > matter:  most (all?) of this type of functionality
> > should be available to end users in the form of
> custom
> > extension functions.  I have found these to be, as
> is
> > the case with many extension APIs, limited only by
> the
> > user's imagination... and in the rare case you
> find
> > that you could do X with extension functions, if
> only
> > change Y would be made to the core library, most
> > projects welcome modifications that enhance users'
> > ability to customize their behavior.
> >
> > HTH,
> > Matt
> >
> > [SNIP]
> >
> >
> >  
> >
>
____________________________________________________________________________________
> > Do you Yahoo!?
> > Everyone is raving about the all-new Yahoo! Mail
> beta.
> > http://new.mail.yahoo.com
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> commons-user-help@jakarta.apache.org
> >
> >
> >   
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-user-help@jakarta.apache.org
> 
> 



 
____________________________________________________________________________________
Have a burning question?  
Go to www.Answers.yahoo.com and get answers from real people who know.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message