You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Tim O'Brien <to...@discursive.com> on 2003/09/07 04:28:50 UTC
[jexl] size method unit test failing
JexlTest line 443: "assertExpression(jc, "array.length", new Integer(5));"
This is failing because (from what I'm seeing), length isn't given any special
treatment in Parser.jjt.
Any ideas?
Tim
Re: [jexl] size method unit test failing
Posted by Peter Royal <pr...@apache.org>.
On Tuesday, September 9, 2003, at 10:13 AM, Geir Magnusson Jr. wrote:
>> 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'.
no problems with the removal here.
>> 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. :)
What's wrong with the mavenized site? I say go for it.
-pete
Re: [jexl] size method unit test failing
Posted by Tim O'Brien <to...@discursive.com>.
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
Re: [jexl] size method unit test failing
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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)
Re: [jexl] size method unit test failing
Posted by Tim O'Brien <to...@discursive.com>.
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?
Tim
Re: [jexl] size method unit test failing
Posted by "Mark H. Wilkinson" <mh...@kremvax.net>.
On Tue, 2003-09-09 at 13:51, Geir Magnusson Jr. wrote:
>
> I think that just using size() is the right way to go.
The only reason I can see to support foo.length for arrays is if the JSP
expression language supports it, on the basis that Jexl claims to be an
extension of the JSP expression language. I can't see an explicit
statement that foo.length should be treated specially in the section of
the JSP 2.0 spec that describes evaluation of . and [], so my conclusion
is that it's not supposed to be part of the standard expression
language. Does anyone have evidence to the contrary? If not then I agree
with geir that the size function would do.
On a related point, JSTL 1.1 has added some standard functions to the
expression language, but they've gone for a length() function rather
than the size() function that Jexl had introduced. Would it make sense
to deprecate size() in favour of length() and JSP EL/JSTL compatibility?
-Mark.
Re: [jexl] size method unit test failing
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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.
> 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.
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.
I'm for the latter.
geir
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
Re: [jexl] size method unit test failing
Posted by Tim O'Brien <to...@discursive.com>.
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, 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?
Re: [jexl] size method unit test failing
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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?
geir
On Tuesday, September 9, 2003, at 06:40 AM, Mark H. Wilkinson wrote:
> On Sun, 2003-09-07 at 03:28, Tim O'Brien wrote:
>> JexlTest line 443: "assertExpression(jc, "array.length", new
>> Integer(5));"
>>
>> This is failing because (from what I'm seeing), length isn't given
>> any special
>> treatment in Parser.jjt.
>>
>> Any ideas?
>
> I proposed the attached fix a few months back, but geir wanted to
> discuss other possible ways of implementing the length function so he
> didn't apply it. There's been no progress since then though.
>
> -Mark.
>
> <array-
> length.patch>----------------------------------------------------------
> -----------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
Re: [jexl] size method unit test failing
Posted by "Mark H. Wilkinson" <mh...@kremvax.net>.
On Sun, 2003-09-07 at 03:28, Tim O'Brien wrote:
> JexlTest line 443: "assertExpression(jc, "array.length", new Integer(5));"
>
> This is failing because (from what I'm seeing), length isn't given any special
> treatment in Parser.jjt.
>
> Any ideas?
I proposed the attached fix a few months back, but geir wanted to
discuss other possible ways of implementing the length function so he
didn't apply it. There's been no progress since then though.
-Mark.