commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim O'Brien <>
Subject Re: [jexl] size method unit test failing
Date Tue, 09 Sep 2003 14:00:05 GMT
On Tue, 2003-09-09 at 07:51, Geir Magnusson Jr. wrote:
> On Tuesday, September 9, 2003, at 08:25 AM, Tim O'Brien wrote:
> > On Tue, 2003-09-09 at 06:58, Geir Magnusson Jr. wrote:
> >> I guess we were going to figure out if we want to add the artificial
> >> notion of the length field, or just ask people to use size().  
> >> 'length'
> >> is really weird, as it doesn't really exist as a field, and only
> >> applies to arrays.
> >>
> >> Why confuse the syntax with an additional way to get size?
> >
> > People may expect "length" to work, but as long as it is properly
> > documented for users I see no problem with asking people to use size()
> > instead of length.
> >
> > "length" is a public final field in all array types,
> It's not actually a field right? (in that it's artifically generated by 
> the compiler, IIRC)  [] aren't objects.

According to the JLS, 2nd ed. {4.3.1} "an object is a class instance or
an array" .  Then according to {10.7} With a public field "length" - it
goes on to demonstrate that an type resembles a class with a public
member length.  My problem with the JLS is that I think section 10.7 is
a lie ( or at least an unkept promise ).  Type creating a "double[]
array" it is certainly an object, but calling
"array.getClass().getFields()" returns a zero-length array. 

So to answer your question, from a *strict* reading of the JLS spec, it
"is" a field [Class.getFields() should return length], but in reality it
is not a field.

> > but from what I see
> > ASTIdentifier just delegates to ASTArrayAccess which then decides how 
> > to
> > deal with an identifier (isMap -> isList -> isArray -> bean prop).
> >
> > We could just as easily add a step after accessing a bean property in
> > ASTArrayAccess which tried to access a public field.  What do you
> > think?
> I think that just using size() is the right way to go.

> We want to avoid the situation where you have to know the exact type of 
> the referent to use it.  Conversely, you'd want the data model to be 
> able to change (say substitute a j.u.List for an []) w/o the script 
> using jexl having to change.

I agree, once I get Generics - I'm going to forget Object[] altogether
and change my code to using collections.   

> If you believe that those two reasons are good, then either you have to 
> make length behave exactly like size(), having two 'methods' that do 
> the exact same thing, or ditch one for clarity and simplicity.

clarity and simplicity plus documentation and we're done.

Shall I remove the offending line from the unit test then?

Speaking of documentation, any objections to updating JEXL's site,
documentation, and changing the commons like to go to the mavenized
project site?


View raw message