commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr. <ge...@optonline.net>
Subject Re: [jexl] size method unit test failing
Date Tue, 09 Sep 2003 14:13:16 GMT

On Tuesday, September 9, 2003, at 10:00 AM, Tim O'Brien wrote:

> 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.
>

Ah. Thanks.  I had just seen it as a creation by the compiler.  Sounds 
like it should be a field then according to the spec, and javac is 
doing it wrong?


>>> 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.

Sometimes I miss C++ :)

>
>>
>> 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?
>

I think so, if no one else has a problem with not having 'length'.

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

Well, I do, but I realize I'm swimming upstream here. :)


-- 
Geir Magnusson Jr                                   203-956-2604(w)
Adeptra, Inc.                                       203-434-2093(m)
geirm@adeptra.com                                   203-247-1713(m)


Mime
View raw message