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 [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
