commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim O'Brien <tobr...@discursive.com>
Subject Re: [jexl] size method unit test failing
Date Tue, 09 Sep 2003 17:54:28 GMT
The offending line in JexlTest has been removed.  If you want the size of 
an array, call "size()".  Now, on to the next target.

http://jakarta.apache.org/commons/jexl/junit-report.html#JexlTest

testNotConditionsWithDots is failing.  Specifically, the following code 
fails:

<code>
Expression e = ExpressionFactory.createExpression("x.a == true");
e.addPostResolver(new FlatResolver());

JexlContext jc = JexlHelper.createContext();
jc.getVars().put("x.a", Boolean.TRUE );

Object o = e.evaluate(jc);
assertEquals("o incorrect", Boolean.TRUE, o );
</code>

In ExpressionImpl.evaluate() when we node.value(context) evaluates to a 
false Boolean object, bypassing the the postResolvers.  "x.a == true" 
turns into an ASTEQNode with ( left = null ) and ( right = Boolean ).  I'm 
wondering what the desired behavior is for this unit test.

Tim 


On Tue, 9 Sep 2003, Geir Magnusson Jr. wrote:

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

-- 
----------------------
Tim O'Brien
Evanston, IL
(847) 863-7045
tobrien@discursive.com



Mime
View raw message