You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Craig L Russell <Cr...@Sun.COM> on 2005/12/26 22:02:32 UTC
Clarification needed on class names in query filters
Javadogs,
The section in 14.6.5 is incomplete. It doesn't address names that
are class names, as in Integer.MAX_VALUE. According to the following,
Integer will be treated as an implicitly defined variable name. :-(
<spec>
Names in the filter are treated as parameters if they are explicitly
declared via declareParameters or if they begin with “:”. A14.6.5-4
[Names are treated as variable names if they are explicitly declared
via declareVariables. Otherwise, names are treated as field names if
they are members of the candidate class. Finally, names are treated
as implicitly defined variable names.]
</spec>
Any suggestions for improvement?
Thanks,
Craig
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Clarification needed on class names in query filters
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Bin,
Yes. it's in red below. Hope you can see red.
Craig
On Jan 3, 2006, at 6:07 PM, Bin Sun wrote:
> Hi!
>
> Excuse me, but I can't see implicit variable
> declaration in this proposal. Am I missing something?
>
> --- Craig L Russell <Cr...@Sun.COM> wrote:
>
>> Hi Michael,
>>
>> Sounds good. One addition below.
>>
>> On Jan 3, 2006, at 3:03 PM, Michael Bouschen wrote:
>>
>>> Hi Craig,
>>>
>>> here is my proposal:
>>>
>>> Names in the filter are treated as parameters if
>> they are
>>> explicitly declared via declareParameters or if
>> they begin with ??
>>> Names are treated as variable names if they are
>> explicitly declared
>>> via declareVariables.
>>> Names are treated as field or property names if
>> they are fields or
>>> properties of the candidate class.
>>> Names are treated as class names if they exist in
>> the package of
>>> the candidate class or have been imported.
>> or if they are in the java.lang package. e.g.
>> Integer. [we did this
>> in other places.]
>>
>> Craig
>>
>>> Names are treated as package names if they are
>> part of the package
>>> qualifier of a class name in a static field
>> access.
>>> Otherwise, names are treated as implicitly defined
>> variable names.
>>> In a dot expression the left to the dot determines
>> the context for
>>> the evaluation of the name to the right of the
>> dot. This name is
>>> never resolved to a parameter or variable.
>>>
>>> Regards Michael
>>>
>>>> Hi Michael,
>>>>
>>>> On Dec 29, 2005, at 3:10 PM, Michael Bouschen
>> wrote:
>>>>
>>>>> Hi Craig,
>>>>>
>>>>>> Hi Michael,
>>>>>>
>>>>>> Could you please try to rewrite the proposal
>> including the class
>>>>>> name bit that you identified below? For some
>> reason, I'm having
>>>>>> a hard time with it.
>>>>>
>>>>>
>>>>> sure, I will try to rewrite.
>>>>
>>>>
>>>> Thanks.
>>>>
>>>>>
>>>>> But I would like clarify first whether JDOQL
>> should support fully
>>>>> qualified class names in static field access or
>> not. So is the
>>>>> following expression legal:
>>>>> this.field > com.xyz.hr.MyClass.MY_STATIC_FIELD
>>>>> or should it be
>>>>> this.field > MyClass.MY_STATIC_FIELD
>>>>> with MyClass being imported.
>>>>
>>>>
>>>> Either should work.
>>>>
>>>> Craig
>>>>
>>>>>
>>>>> Regards Michael
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Craig
>>>>>>
>>>>>> On Dec 29, 2005, at 1:00 PM, Michael Bouschen
>> wrote:
>>>>>>
>>>>>>> Hi Craig,
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>>
>>>>>>>>> I like your proposal: "... members of the
>> candidate class, or
>>>>>>>>> they are qualified by the class and can be
>> resolved to a
>>>>>>>>> static field of that name in the specified
>> class....". Please
>>>>>>>>> note this includes that the the class
>> qualifier might be a
>>>>>>>>> fully qualified class name. So for a path
>> expression 'a.b.c'
>>>>>>>>> the query compiler needs to analyze the
>> entire path
>>>>>>>>> expression, before it can decide that 'a' is
>> an implicit
>>>>>>>>> variable.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I was hoping for a rule that would allow the
>> compiler to
>>>>>>>> determine that "a" is a class name not an
>> implicit variable,
>>>>>>>> without using the existence of b.c in a to
>> determine it.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The case that 'a' is a class name is easy. The
>> compiler can
>>>>>>> check if 'a' is in the the package of the
>> candidate class or is
>>>>>>> imported. And there is no need to look at
>> 'b.c' to resolve 'a'.
>>>>>>>
>>>>>>> The analysis gets complicated if 'a' is part
>> of the package
>>>>>>> name in a fully qualified class name, e.g.
>>>>>>> com.xyz.hr.MyClass.MY_STATIC_FIELD. Here the
>> compiler should
>>>>>>> not treat 'com' as an implicit variable. But
>> it needs to
>>>>>>> analyze 'com.xyz.hr.MyClass' before it can
>> decide that 'com' is
>>>>>>> part of a package name.
>>>>>>>
>>>>>>>> Due to the common practice of starting
>> variable names with
>>>>>>>> lower-case and classes with upper-case, I
>> think that this is
>>>>>>>> probably a corner case.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> For the user this is a corner case, but not
>> for the compiler.
>>>>>>> It does not pay attention to common practice
>> of identifier
>>>>>>> naming :-).
>>>>>>>
>>>>>>>> But I'm still hoping that we can have an
>> unambiguous rule,
>>>>>>>> inserting something into the rule below after
>> "names are
>>>>>>>> treated as field names if they are members of
>> the candidate
>>>>>>>> class": "Names are treated as a class name
>> if it exists in
>>>>>>>> the package of the candidate class or has
>> been imported".
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This is more clear, but it does not allow
>> fully qualified class
>>>>>>> names in a static field access expression.
>> This might be ok,
>>>>>>> given the fact that a static field access will
>> not be very
>>>>>>> common in a JDOQL query. But the spec should
>> explicitly state
>>>>>>> this, since this is different in other parts
>> of JDOQL: you can
>>>>>>> use a fully qualified class in
>> variable/parameter declarations
>>>>>>> or in cast expressions.
>>>>>>>
>>>>>>> Regards Michael
>>>>>>>
>>>>>>>>
>>>>>>>> Craig
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards Michael
>>>>>>>>>
>>>>>>>>>> Hi Craig,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> <spec>
>>>>>>>>>>> Names in the filter are treated as
>> parameters if they are
>>>>>>>>>>> explicitly
>>>>>>>>>>> declared via declareParameters or if they
>> begin with ??
>>>>>>>>>>> A14.6.5-4
>>
> === message truncated ===
>
>
>
>
> __________________________________________
> Yahoo! DSL – Something to write home about.
> Just $16.99/mo. or less.
> dsl.yahoo.com
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Clarification needed on class names in query filters
Posted by Bin Sun <su...@yahoo.com>.
Hi!
Excuse me, but I can't see implicit variable
declaration in this proposal. Am I missing something?
--- Craig L Russell <Cr...@Sun.COM> wrote:
> Hi Michael,
>
> Sounds good. One addition below.
>
> On Jan 3, 2006, at 3:03 PM, Michael Bouschen wrote:
>
> > Hi Craig,
> >
> > here is my proposal:
> >
> > Names in the filter are treated as parameters if
> they are
> > explicitly declared via declareParameters or if
> they begin with ??
> > Names are treated as variable names if they are
> explicitly declared
> > via declareVariables.
> > Names are treated as field or property names if
> they are fields or
> > properties of the candidate class.
> > Names are treated as class names if they exist in
> the package of
> > the candidate class or have been imported.
> or if they are in the java.lang package. e.g.
> Integer. [we did this
> in other places.]
>
> Craig
>
> > Names are treated as package names if they are
> part of the package
> > qualifier of a class name in a static field
> access.
> > Otherwise, names are treated as implicitly defined
> variable names.
> > In a dot expression the left to the dot determines
> the context for
> > the evaluation of the name to the right of the
> dot. This name is
> > never resolved to a parameter or variable.
> >
> > Regards Michael
> >
> >> Hi Michael,
> >>
> >> On Dec 29, 2005, at 3:10 PM, Michael Bouschen
> wrote:
> >>
> >>> Hi Craig,
> >>>
> >>>> Hi Michael,
> >>>>
> >>>> Could you please try to rewrite the proposal
> including the class
> >>>> name bit that you identified below? For some
> reason, I'm having
> >>>> a hard time with it.
> >>>
> >>>
> >>> sure, I will try to rewrite.
> >>
> >>
> >> Thanks.
> >>
> >>>
> >>> But I would like clarify first whether JDOQL
> should support fully
> >>> qualified class names in static field access or
> not. So is the
> >>> following expression legal:
> >>> this.field > com.xyz.hr.MyClass.MY_STATIC_FIELD
> >>> or should it be
> >>> this.field > MyClass.MY_STATIC_FIELD
> >>> with MyClass being imported.
> >>
> >>
> >> Either should work.
> >>
> >> Craig
> >>
> >>>
> >>> Regards Michael
> >>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Craig
> >>>>
> >>>> On Dec 29, 2005, at 1:00 PM, Michael Bouschen
> wrote:
> >>>>
> >>>>> Hi Craig,
> >>>>>
> >>>>> [...]
> >>>>>
> >>>>>>
> >>>>>>> I like your proposal: "... members of the
> candidate class, or
> >>>>>>> they are qualified by the class and can be
> resolved to a
> >>>>>>> static field of that name in the specified
> class....". Please
> >>>>>>> note this includes that the the class
> qualifier might be a
> >>>>>>> fully qualified class name. So for a path
> expression 'a.b.c'
> >>>>>>> the query compiler needs to analyze the
> entire path
> >>>>>>> expression, before it can decide that 'a' is
> an implicit
> >>>>>>> variable.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I was hoping for a rule that would allow the
> compiler to
> >>>>>> determine that "a" is a class name not an
> implicit variable,
> >>>>>> without using the existence of b.c in a to
> determine it.
> >>>>>
> >>>>>
> >>>>>
> >>>>> The case that 'a' is a class name is easy. The
> compiler can
> >>>>> check if 'a' is in the the package of the
> candidate class or is
> >>>>> imported. And there is no need to look at
> 'b.c' to resolve 'a'.
> >>>>>
> >>>>> The analysis gets complicated if 'a' is part
> of the package
> >>>>> name in a fully qualified class name, e.g.
> >>>>> com.xyz.hr.MyClass.MY_STATIC_FIELD. Here the
> compiler should
> >>>>> not treat 'com' as an implicit variable. But
> it needs to
> >>>>> analyze 'com.xyz.hr.MyClass' before it can
> decide that 'com' is
> >>>>> part of a package name.
> >>>>>
> >>>>>> Due to the common practice of starting
> variable names with
> >>>>>> lower-case and classes with upper-case, I
> think that this is
> >>>>>> probably a corner case.
> >>>>>
> >>>>>
> >>>>>
> >>>>> For the user this is a corner case, but not
> for the compiler.
> >>>>> It does not pay attention to common practice
> of identifier
> >>>>> naming :-).
> >>>>>
> >>>>>> But I'm still hoping that we can have an
> unambiguous rule,
> >>>>>> inserting something into the rule below after
> "names are
> >>>>>> treated as field names if they are members of
> the candidate
> >>>>>> class": "Names are treated as a class name
> if it exists in
> >>>>>> the package of the candidate class or has
> been imported".
> >>>>>
> >>>>>
> >>>>>
> >>>>> This is more clear, but it does not allow
> fully qualified class
> >>>>> names in a static field access expression.
> This might be ok,
> >>>>> given the fact that a static field access will
> not be very
> >>>>> common in a JDOQL query. But the spec should
> explicitly state
> >>>>> this, since this is different in other parts
> of JDOQL: you can
> >>>>> use a fully qualified class in
> variable/parameter declarations
> >>>>> or in cast expressions.
> >>>>>
> >>>>> Regards Michael
> >>>>>
> >>>>>>
> >>>>>> Craig
> >>>>>>
> >>>>>>>
> >>>>>>> Regards Michael
> >>>>>>>
> >>>>>>>> Hi Craig,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> <spec>
> >>>>>>>>> Names in the filter are treated as
> parameters if they are
> >>>>>>>>> explicitly
> >>>>>>>>> declared via declareParameters or if they
> begin with ??
> >>>>>>>>> A14.6.5-4
>
=== message truncated ===
__________________________________________
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
Re: Clarification needed on class names in query filters
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Michael,
Sounds good. One addition below.
On Jan 3, 2006, at 3:03 PM, Michael Bouschen wrote:
> Hi Craig,
>
> here is my proposal:
>
> Names in the filter are treated as parameters if they are
> explicitly declared via declareParameters or if they begin with “:”.
> Names are treated as variable names if they are explicitly declared
> via declareVariables.
> Names are treated as field or property names if they are fields or
> properties of the candidate class.
> Names are treated as class names if they exist in the package of
> the candidate class or have been imported.
or if they are in the java.lang package. e.g. Integer. [we did this
in other places.]
Craig
> Names are treated as package names if they are part of the package
> qualifier of a class name in a static field access.
> Otherwise, names are treated as implicitly defined variable names.
> In a dot expression the left to the dot determines the context for
> the evaluation of the name to the right of the dot. This name is
> never resolved to a parameter or variable.
>
> Regards Michael
>
>> Hi Michael,
>>
>> On Dec 29, 2005, at 3:10 PM, Michael Bouschen wrote:
>>
>>> Hi Craig,
>>>
>>>> Hi Michael,
>>>>
>>>> Could you please try to rewrite the proposal including the class
>>>> name bit that you identified below? For some reason, I'm having
>>>> a hard time with it.
>>>
>>>
>>> sure, I will try to rewrite.
>>
>>
>> Thanks.
>>
>>>
>>> But I would like clarify first whether JDOQL should support fully
>>> qualified class names in static field access or not. So is the
>>> following expression legal:
>>> this.field > com.xyz.hr.MyClass.MY_STATIC_FIELD
>>> or should it be
>>> this.field > MyClass.MY_STATIC_FIELD
>>> with MyClass being imported.
>>
>>
>> Either should work.
>>
>> Craig
>>
>>>
>>> Regards Michael
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Craig
>>>>
>>>> On Dec 29, 2005, at 1:00 PM, Michael Bouschen wrote:
>>>>
>>>>> Hi Craig,
>>>>>
>>>>> [...]
>>>>>
>>>>>>
>>>>>>> I like your proposal: "... members of the candidate class, or
>>>>>>> they are qualified by the class and can be resolved to a
>>>>>>> static field of that name in the specified class....". Please
>>>>>>> note this includes that the the class qualifier might be a
>>>>>>> fully qualified class name. So for a path expression 'a.b.c'
>>>>>>> the query compiler needs to analyze the entire path
>>>>>>> expression, before it can decide that 'a' is an implicit
>>>>>>> variable.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I was hoping for a rule that would allow the compiler to
>>>>>> determine that "a" is a class name not an implicit variable,
>>>>>> without using the existence of b.c in a to determine it.
>>>>>
>>>>>
>>>>>
>>>>> The case that 'a' is a class name is easy. The compiler can
>>>>> check if 'a' is in the the package of the candidate class or is
>>>>> imported. And there is no need to look at 'b.c' to resolve 'a'.
>>>>>
>>>>> The analysis gets complicated if 'a' is part of the package
>>>>> name in a fully qualified class name, e.g.
>>>>> com.xyz.hr.MyClass.MY_STATIC_FIELD. Here the compiler should
>>>>> not treat 'com' as an implicit variable. But it needs to
>>>>> analyze 'com.xyz.hr.MyClass' before it can decide that 'com' is
>>>>> part of a package name.
>>>>>
>>>>>> Due to the common practice of starting variable names with
>>>>>> lower-case and classes with upper-case, I think that this is
>>>>>> probably a corner case.
>>>>>
>>>>>
>>>>>
>>>>> For the user this is a corner case, but not for the compiler.
>>>>> It does not pay attention to common practice of identifier
>>>>> naming :-).
>>>>>
>>>>>> But I'm still hoping that we can have an unambiguous rule,
>>>>>> inserting something into the rule below after "names are
>>>>>> treated as field names if they are members of the candidate
>>>>>> class": "Names are treated as a class name if it exists in
>>>>>> the package of the candidate class or has been imported".
>>>>>
>>>>>
>>>>>
>>>>> This is more clear, but it does not allow fully qualified class
>>>>> names in a static field access expression. This might be ok,
>>>>> given the fact that a static field access will not be very
>>>>> common in a JDOQL query. But the spec should explicitly state
>>>>> this, since this is different in other parts of JDOQL: you can
>>>>> use a fully qualified class in variable/parameter declarations
>>>>> or in cast expressions.
>>>>>
>>>>> Regards Michael
>>>>>
>>>>>>
>>>>>> Craig
>>>>>>
>>>>>>>
>>>>>>> Regards Michael
>>>>>>>
>>>>>>>> Hi Craig,
>>>>>>>>
>>>>>>>>
>>>>>>>>> <spec>
>>>>>>>>> Names in the filter are treated as parameters if they are
>>>>>>>>> explicitly
>>>>>>>>> declared via declareParameters or if they begin with “:”.
>>>>>>>>> A14.6.5-4
>>>>>>>>> [Names are treated as variable names if they are explicitly
>>>>>>>>> declared
>>>>>>>>> via declareVariables. Otherwise, names are treated as field
>>>>>>>>> names if
>>>>>>>>> they are members of the candidate class. Finally, names are
>>>>>>>>> treated
>>>>>>>>> as implicitly defined variable names.]
>>>>>>>>> </spec>
>>>>>>>>>
>>>>>>>>> Any suggestions for improvement?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> How about this :-
>>>>>>>>
>>>>>>>> <spec>
>>>>>>>> Names in the filter are treated as parameters if they are
>>>>>>>> explicitly
>>>>>>>> declared via declareParameters or if they begin with “:”.
>>>>>>>> Names are treated as variable names if they are explicitly
>>>>>>>> declared
>>>>>>>> via declareVariables.
>>>>>>>> Names are treated as field names if they are either members
>>>>>>>> of the candidate class, or they are qualified by the class
>>>>>>>> and can be resolved to a static field of that name in the
>>>>>>>> specified class.
>>>>>>>> Otherwise, names are treated as implicitly defined variable
>>>>>>>> names.
>>>>>>>> </spec>
>>>>>>>>
>>>>>>>> This then allows access to static fields in *all* classes
>>>>>>>> and not just the java.lang classes. So a user can specify
>>>>>>>> Integer.MAX_VALUE, MyClass.MY_STATIC_FIELD,
>>>>>>>> java.awt.Color.BLACK or whatever and since they are prefixed
>>>>>>>> by the class name, the (static) field will be found and can
>>>>>>>> be used.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Michael Bouschen Tech@Spree Engineering GmbH
>>>>>>> mailto:mbo.tech@spree.de http://www.tech.spree.de/
>>>>>>> Tel.:++49/30/235 520-33 Buelowstr. 66
>>>>>>> Fax.:++49/30/2175 2012 D-10783 Berlin
>>>>>>>
>>>>>>
>>>>>> Craig Russell
>>>>>>
>>>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>>>> products/jdo
>>>>>>
>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>
>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael Bouschen Tech@Spree Engineering GmbH
>>>>> mailto:mbo.tech@spree.de http://www.tech.spree.de/
>>>>> Tel.:++49/30/235 520-33 Buelowstr. 66
>>>>> Fax.:++49/30/2175 2012 D-10783 Berlin
>>>>>
>>>>
>>>> Craig Russell
>>>>
>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>> products/jdo
>>>>
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>>
>>>
>>>
>>> --
>>> Michael Bouschen Tech@Spree Engineering GmbH
>>> mailto:mbo.tech@spree.de http://www.tech.spree.de/
>>> Tel.:++49/30/235 520-33 Buelowstr. 66
>>> Fax.:++49/30/2175 2012 D-10783 Berlin
>>>
>>
>> Craig Russell
>>
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>>
>> 408 276-5638 mailto:Craig.Russell@sun.com
>>
>> P.S. A good JDO? O, Gasp!
>>
>>
>
>
> --
> Michael Bouschen Tech@Spree Engineering GmbH
> mailto:mbo.tech@spree.de http://www.tech.spree.de/
> Tel.:++49/30/235 520-33 Buelowstr. 66
> Fax.:++49/30/2175 2012 D-10783 Berlin
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Clarification needed on class names in query filters
Posted by Michael Bouschen <mb...@spree.de>.
Hi Craig,
here is my proposal:
Names in the filter are treated as parameters if they are explicitly
declared via declareParameters or if they begin with “:”.
Names are treated as variable names if they are explicitly declared via
declareVariables.
Names are treated as field or property names if they are fields or
properties of the candidate class.
Names are treated as class names if they exist in the package of the
candidate class or have been imported.
Names are treated as package names if they are part of the package
qualifier of a class name in a static field access.
Otherwise, names are treated as implicitly defined variable names.
In a dot expression the left to the dot determines the context for the
evaluation of the name to the right of the dot. This name is never
resolved to a parameter or variable.
Regards Michael
> Hi Michael,
>
> On Dec 29, 2005, at 3:10 PM, Michael Bouschen wrote:
>
>> Hi Craig,
>>
>>> Hi Michael,
>>>
>>> Could you please try to rewrite the proposal including the class
>>> name bit that you identified below? For some reason, I'm having a
>>> hard time with it.
>>
>>
>> sure, I will try to rewrite.
>
>
> Thanks.
>
>>
>> But I would like clarify first whether JDOQL should support fully
>> qualified class names in static field access or not. So is the
>> following expression legal:
>> this.field > com.xyz.hr.MyClass.MY_STATIC_FIELD
>> or should it be
>> this.field > MyClass.MY_STATIC_FIELD
>> with MyClass being imported.
>
>
> Either should work.
>
> Craig
>
>>
>> Regards Michael
>>
>>>
>>> Thanks,
>>>
>>> Craig
>>>
>>> On Dec 29, 2005, at 1:00 PM, Michael Bouschen wrote:
>>>
>>>> Hi Craig,
>>>>
>>>> [...]
>>>>
>>>>>
>>>>>> I like your proposal: "... members of the candidate class, or
>>>>>> they are qualified by the class and can be resolved to a static
>>>>>> field of that name in the specified class....". Please note this
>>>>>> includes that the the class qualifier might be a fully qualified
>>>>>> class name. So for a path expression 'a.b.c' the query compiler
>>>>>> needs to analyze the entire path expression, before it can decide
>>>>>> that 'a' is an implicit variable.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I was hoping for a rule that would allow the compiler to determine
>>>>> that "a" is a class name not an implicit variable, without using
>>>>> the existence of b.c in a to determine it.
>>>>
>>>>
>>>>
>>>> The case that 'a' is a class name is easy. The compiler can check
>>>> if 'a' is in the the package of the candidate class or is imported.
>>>> And there is no need to look at 'b.c' to resolve 'a'.
>>>>
>>>> The analysis gets complicated if 'a' is part of the package name in
>>>> a fully qualified class name, e.g.
>>>> com.xyz.hr.MyClass.MY_STATIC_FIELD. Here the compiler should not
>>>> treat 'com' as an implicit variable. But it needs to analyze
>>>> 'com.xyz.hr.MyClass' before it can decide that 'com' is part of a
>>>> package name.
>>>>
>>>>> Due to the common practice of starting variable names with
>>>>> lower-case and classes with upper-case, I think that this is
>>>>> probably a corner case.
>>>>
>>>>
>>>>
>>>> For the user this is a corner case, but not for the compiler. It
>>>> does not pay attention to common practice of identifier naming :-).
>>>>
>>>>> But I'm still hoping that we can have an unambiguous rule,
>>>>> inserting something into the rule below after "names are treated
>>>>> as field names if they are members of the candidate class":
>>>>> "Names are treated as a class name if it exists in the package of
>>>>> the candidate class or has been imported".
>>>>
>>>>
>>>>
>>>> This is more clear, but it does not allow fully qualified class
>>>> names in a static field access expression. This might be ok, given
>>>> the fact that a static field access will not be very common in a
>>>> JDOQL query. But the spec should explicitly state this, since this
>>>> is different in other parts of JDOQL: you can use a fully qualified
>>>> class in variable/parameter declarations or in cast expressions.
>>>>
>>>> Regards Michael
>>>>
>>>>>
>>>>> Craig
>>>>>
>>>>>>
>>>>>> Regards Michael
>>>>>>
>>>>>>> Hi Craig,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> <spec>
>>>>>>>> Names in the filter are treated as parameters if they are
>>>>>>>> explicitly
>>>>>>>> declared via declareParameters or if they begin with “:”. A14.6.5-4
>>>>>>>> [Names are treated as variable names if they are explicitly
>>>>>>>> declared
>>>>>>>> via declareVariables. Otherwise, names are treated as field
>>>>>>>> names if
>>>>>>>> they are members of the candidate class. Finally, names are treated
>>>>>>>> as implicitly defined variable names.]
>>>>>>>> </spec>
>>>>>>>>
>>>>>>>> Any suggestions for improvement?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> How about this :-
>>>>>>>
>>>>>>> <spec>
>>>>>>> Names in the filter are treated as parameters if they are explicitly
>>>>>>> declared via declareParameters or if they begin with “:”.
>>>>>>> Names are treated as variable names if they are explicitly declared
>>>>>>> via declareVariables.
>>>>>>> Names are treated as field names if they are either members of
>>>>>>> the candidate class, or they are qualified by the class and can
>>>>>>> be resolved to a static field of that name in the specified class.
>>>>>>> Otherwise, names are treated as implicitly defined variable names.
>>>>>>> </spec>
>>>>>>>
>>>>>>> This then allows access to static fields in *all* classes and
>>>>>>> not just the java.lang classes. So a user can specify
>>>>>>> Integer.MAX_VALUE, MyClass.MY_STATIC_FIELD, java.awt.Color.BLACK
>>>>>>> or whatever and since they are prefixed by the class name, the
>>>>>>> (static) field will be found and can be used.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Michael Bouschen Tech@Spree Engineering GmbH
>>>>>> mailto:mbo.tech@spree.de http://www.tech.spree.de/
>>>>>> Tel.:++49/30/235 520-33 Buelowstr. 66
>>>>>> Fax.:++49/30/2175 2012 D-10783 Berlin
>>>>>>
>>>>>
>>>>> Craig Russell
>>>>>
>>>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>>>>
>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>
>>>>> P.S. A good JDO? O, Gasp!
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Michael Bouschen Tech@Spree Engineering GmbH
>>>> mailto:mbo.tech@spree.de http://www.tech.spree.de/
>>>> Tel.:++49/30/235 520-33 Buelowstr. 66
>>>> Fax.:++49/30/2175 2012 D-10783 Berlin
>>>>
>>>
>>> Craig Russell
>>>
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>>
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>
>>
>> --
>> Michael Bouschen Tech@Spree Engineering GmbH
>> mailto:mbo.tech@spree.de http://www.tech.spree.de/
>> Tel.:++49/30/235 520-33 Buelowstr. 66
>> Fax.:++49/30/2175 2012 D-10783 Berlin
>>
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com
>
> P.S. A good JDO? O, Gasp!
>
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
Re: Clarification needed on class names in query filters
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Michael,
On Dec 29, 2005, at 3:10 PM, Michael Bouschen wrote:
> Hi Craig,
>
>> Hi Michael,
>>
>> Could you please try to rewrite the proposal including the class
>> name bit that you identified below? For some reason, I'm having a
>> hard time with it.
>
> sure, I will try to rewrite.
Thanks.
>
> But I would like clarify first whether JDOQL should support fully
> qualified class names in static field access or not. So is the
> following expression legal:
> this.field > com.xyz.hr.MyClass.MY_STATIC_FIELD
> or should it be
> this.field > MyClass.MY_STATIC_FIELD
> with MyClass being imported.
Either should work.
Craig
>
> Regards Michael
>
>>
>> Thanks,
>>
>> Craig
>>
>> On Dec 29, 2005, at 1:00 PM, Michael Bouschen wrote:
>>
>>> Hi Craig,
>>>
>>> [...]
>>>
>>>>
>>>>> I like your proposal: "... members of the candidate class, or
>>>>> they are qualified by the class and can be resolved to a static
>>>>> field of that name in the specified class....". Please note
>>>>> this includes that the the class qualifier might be a fully
>>>>> qualified class name. So for a path expression 'a.b.c' the
>>>>> query compiler needs to analyze the entire path expression,
>>>>> before it can decide that 'a' is an implicit variable.
>>>>
>>>>
>>>>
>>>> I was hoping for a rule that would allow the compiler to
>>>> determine that "a" is a class name not an implicit variable,
>>>> without using the existence of b.c in a to determine it.
>>>
>>>
>>> The case that 'a' is a class name is easy. The compiler can check
>>> if 'a' is in the the package of the candidate class or is
>>> imported. And there is no need to look at 'b.c' to resolve 'a'.
>>>
>>> The analysis gets complicated if 'a' is part of the package name
>>> in a fully qualified class name, e.g.
>>> com.xyz.hr.MyClass.MY_STATIC_FIELD. Here the compiler should not
>>> treat 'com' as an implicit variable. But it needs to analyze
>>> 'com.xyz.hr.MyClass' before it can decide that 'com' is part of a
>>> package name.
>>>
>>>> Due to the common practice of starting variable names with lower-
>>>> case and classes with upper-case, I think that this is probably
>>>> a corner case.
>>>
>>>
>>> For the user this is a corner case, but not for the compiler. It
>>> does not pay attention to common practice of identifier naming :-).
>>>
>>>> But I'm still hoping that we can have an unambiguous rule,
>>>> inserting something into the rule below after "names are treated
>>>> as field names if they are members of the candidate class":
>>>> "Names are treated as a class name if it exists in the package
>>>> of the candidate class or has been imported".
>>>
>>>
>>> This is more clear, but it does not allow fully qualified class
>>> names in a static field access expression. This might be ok,
>>> given the fact that a static field access will not be very common
>>> in a JDOQL query. But the spec should explicitly state this,
>>> since this is different in other parts of JDOQL: you can use a
>>> fully qualified class in variable/parameter declarations or in
>>> cast expressions.
>>>
>>> Regards Michael
>>>
>>>>
>>>> Craig
>>>>
>>>>>
>>>>> Regards Michael
>>>>>
>>>>>> Hi Craig,
>>>>>>
>>>>>>
>>>>>>> <spec>
>>>>>>> Names in the filter are treated as parameters if they are
>>>>>>> explicitly
>>>>>>> declared via declareParameters or if they begin with “:”.
>>>>>>> A14.6.5-4
>>>>>>> [Names are treated as variable names if they are explicitly
>>>>>>> declared
>>>>>>> via declareVariables. Otherwise, names are treated as field
>>>>>>> names if
>>>>>>> they are members of the candidate class. Finally, names are
>>>>>>> treated
>>>>>>> as implicitly defined variable names.]
>>>>>>> </spec>
>>>>>>>
>>>>>>> Any suggestions for improvement?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> How about this :-
>>>>>>
>>>>>> <spec>
>>>>>> Names in the filter are treated as parameters if they are
>>>>>> explicitly
>>>>>> declared via declareParameters or if they begin with “:”.
>>>>>> Names are treated as variable names if they are explicitly
>>>>>> declared
>>>>>> via declareVariables.
>>>>>> Names are treated as field names if they are either members of
>>>>>> the candidate class, or they are qualified by the class and
>>>>>> can be resolved to a static field of that name in the
>>>>>> specified class.
>>>>>> Otherwise, names are treated as implicitly defined variable
>>>>>> names.
>>>>>> </spec>
>>>>>>
>>>>>> This then allows access to static fields in *all* classes and
>>>>>> not just the java.lang classes. So a user can specify
>>>>>> Integer.MAX_VALUE, MyClass.MY_STATIC_FIELD,
>>>>>> java.awt.Color.BLACK or whatever and since they are prefixed
>>>>>> by the class name, the (static) field will be found and can be
>>>>>> used.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael Bouschen Tech@Spree Engineering GmbH
>>>>> mailto:mbo.tech@spree.de http://www.tech.spree.de/
>>>>> Tel.:++49/30/235 520-33 Buelowstr. 66
>>>>> Fax.:++49/30/2175 2012 D-10783 Berlin
>>>>>
>>>>
>>>> Craig Russell
>>>>
>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>> products/jdo
>>>>
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>>
>>>
>>>
>>> --
>>> Michael Bouschen Tech@Spree Engineering GmbH
>>> mailto:mbo.tech@spree.de http://www.tech.spree.de/
>>> Tel.:++49/30/235 520-33 Buelowstr. 66
>>> Fax.:++49/30/2175 2012 D-10783 Berlin
>>>
>>
>> Craig Russell
>>
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>>
>> 408 276-5638 mailto:Craig.Russell@sun.com
>>
>> P.S. A good JDO? O, Gasp!
>>
>>
>
>
> --
> Michael Bouschen Tech@Spree Engineering GmbH
> mailto:mbo.tech@spree.de http://www.tech.spree.de/
> Tel.:++49/30/235 520-33 Buelowstr. 66
> Fax.:++49/30/2175 2012 D-10783 Berlin
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Clarification needed on class names in query filters
Posted by Michael Bouschen <mb...@spree.de>.
Hi Craig,
> Hi Michael,
>
> Could you please try to rewrite the proposal including the class name
> bit that you identified below? For some reason, I'm having a hard time
> with it.
sure, I will try to rewrite.
But I would like clarify first whether JDOQL should support fully
qualified class names in static field access or not. So is the following
expression legal:
this.field > com.xyz.hr.MyClass.MY_STATIC_FIELD
or should it be
this.field > MyClass.MY_STATIC_FIELD
with MyClass being imported.
Regards Michael
>
> Thanks,
>
> Craig
>
> On Dec 29, 2005, at 1:00 PM, Michael Bouschen wrote:
>
>> Hi Craig,
>>
>> [...]
>>
>>>
>>>> I like your proposal: "... members of the candidate class, or they
>>>> are qualified by the class and can be resolved to a static field of
>>>> that name in the specified class....". Please note this includes
>>>> that the the class qualifier might be a fully qualified class name.
>>>> So for a path expression 'a.b.c' the query compiler needs to
>>>> analyze the entire path expression, before it can decide that 'a'
>>>> is an implicit variable.
>>>
>>>
>>>
>>> I was hoping for a rule that would allow the compiler to determine
>>> that "a" is a class name not an implicit variable, without using the
>>> existence of b.c in a to determine it.
>>
>>
>> The case that 'a' is a class name is easy. The compiler can check if
>> 'a' is in the the package of the candidate class or is imported. And
>> there is no need to look at 'b.c' to resolve 'a'.
>>
>> The analysis gets complicated if 'a' is part of the package name in a
>> fully qualified class name, e.g. com.xyz.hr.MyClass.MY_STATIC_FIELD.
>> Here the compiler should not treat 'com' as an implicit variable. But
>> it needs to analyze 'com.xyz.hr.MyClass' before it can decide that
>> 'com' is part of a package name.
>>
>>> Due to the common practice of starting variable names with
>>> lower-case and classes with upper-case, I think that this is
>>> probably a corner case.
>>
>>
>> For the user this is a corner case, but not for the compiler. It does
>> not pay attention to common practice of identifier naming :-).
>>
>>> But I'm still hoping that we can have an unambiguous rule, inserting
>>> something into the rule below after "names are treated as field
>>> names if they are members of the candidate class": "Names are
>>> treated as a class name if it exists in the package of the candidate
>>> class or has been imported".
>>
>>
>> This is more clear, but it does not allow fully qualified class names
>> in a static field access expression. This might be ok, given the fact
>> that a static field access will not be very common in a JDOQL query.
>> But the spec should explicitly state this, since this is different in
>> other parts of JDOQL: you can use a fully qualified class in
>> variable/parameter declarations or in cast expressions.
>>
>> Regards Michael
>>
>>>
>>> Craig
>>>
>>>>
>>>> Regards Michael
>>>>
>>>>> Hi Craig,
>>>>>
>>>>>
>>>>>
>>>>>> <spec>
>>>>>> Names in the filter are treated as parameters if they are explicitly
>>>>>> declared via declareParameters or if they begin with “:”. A14.6.5-4
>>>>>> [Names are treated as variable names if they are explicitly declared
>>>>>> via declareVariables. Otherwise, names are treated as field names if
>>>>>> they are members of the candidate class. Finally, names are treated
>>>>>> as implicitly defined variable names.]
>>>>>> </spec>
>>>>>>
>>>>>> Any suggestions for improvement?
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> How about this :-
>>>>>
>>>>> <spec>
>>>>> Names in the filter are treated as parameters if they are explicitly
>>>>> declared via declareParameters or if they begin with “:”.
>>>>> Names are treated as variable names if they are explicitly declared
>>>>> via declareVariables.
>>>>> Names are treated as field names if they are either members of the
>>>>> candidate class, or they are qualified by the class and can be
>>>>> resolved to a static field of that name in the specified class.
>>>>> Otherwise, names are treated as implicitly defined variable names.
>>>>> </spec>
>>>>>
>>>>> This then allows access to static fields in *all* classes and not
>>>>> just the java.lang classes. So a user can specify
>>>>> Integer.MAX_VALUE, MyClass.MY_STATIC_FIELD, java.awt.Color.BLACK
>>>>> or whatever and since they are prefixed by the class name, the
>>>>> (static) field will be found and can be used.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Michael Bouschen Tech@Spree Engineering GmbH
>>>> mailto:mbo.tech@spree.de http://www.tech.spree.de/
>>>> Tel.:++49/30/235 520-33 Buelowstr. 66
>>>> Fax.:++49/30/2175 2012 D-10783 Berlin
>>>>
>>>
>>> Craig Russell
>>>
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>>
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>
>>
>> --
>> Michael Bouschen Tech@Spree Engineering GmbH
>> mailto:mbo.tech@spree.de http://www.tech.spree.de/
>> Tel.:++49/30/235 520-33 Buelowstr. 66
>> Fax.:++49/30/2175 2012 D-10783 Berlin
>>
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com
>
> P.S. A good JDO? O, Gasp!
>
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
Re: Clarification needed on class names in query filters
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Michael,
Could you please try to rewrite the proposal including the class name
bit that you identified below? For some reason, I'm having a hard
time with it.
Thanks,
Craig
On Dec 29, 2005, at 1:00 PM, Michael Bouschen wrote:
> Hi Craig,
>
> [...]
>
>>
>>> I like your proposal: "... members of the candidate class, or
>>> they are qualified by the class and can be resolved to a static
>>> field of that name in the specified class....". Please note this
>>> includes that the the class qualifier might be a fully qualified
>>> class name. So for a path expression 'a.b.c' the query compiler
>>> needs to analyze the entire path expression, before it can decide
>>> that 'a' is an implicit variable.
>>
>>
>> I was hoping for a rule that would allow the compiler to determine
>> that "a" is a class name not an implicit variable, without using
>> the existence of b.c in a to determine it.
>
> The case that 'a' is a class name is easy. The compiler can check
> if 'a' is in the the package of the candidate class or is imported.
> And there is no need to look at 'b.c' to resolve 'a'.
>
> The analysis gets complicated if 'a' is part of the package name in
> a fully qualified class name, e.g.
> com.xyz.hr.MyClass.MY_STATIC_FIELD. Here the compiler should not
> treat 'com' as an implicit variable. But it needs to analyze
> 'com.xyz.hr.MyClass' before it can decide that 'com' is part of a
> package name.
>
>> Due to the common practice of starting variable names with lower-
>> case and classes with upper-case, I think that this is probably a
>> corner case.
>
> For the user this is a corner case, but not for the compiler. It
> does not pay attention to common practice of identifier naming :-).
>
>> But I'm still hoping that we can have an unambiguous rule,
>> inserting something into the rule below after "names are treated
>> as field names if they are members of the candidate class":
>> "Names are treated as a class name if it exists in the package of
>> the candidate class or has been imported".
>
> This is more clear, but it does not allow fully qualified class
> names in a static field access expression. This might be ok, given
> the fact that a static field access will not be very common in a
> JDOQL query. But the spec should explicitly state this, since this
> is different in other parts of JDOQL: you can use a fully qualified
> class in variable/parameter declarations or in cast expressions.
>
> Regards Michael
>
>>
>> Craig
>>
>>>
>>> Regards Michael
>>>
>>>> Hi Craig,
>>>>
>>>>
>>>>> <spec>
>>>>> Names in the filter are treated as parameters if they are
>>>>> explicitly
>>>>> declared via declareParameters or if they begin with “:”.
>>>>> A14.6.5-4
>>>>> [Names are treated as variable names if they are explicitly
>>>>> declared
>>>>> via declareVariables. Otherwise, names are treated as field
>>>>> names if
>>>>> they are members of the candidate class. Finally, names are
>>>>> treated
>>>>> as implicitly defined variable names.]
>>>>> </spec>
>>>>>
>>>>> Any suggestions for improvement?
>>>>>
>>>>>
>>>>
>>>> How about this :-
>>>>
>>>> <spec>
>>>> Names in the filter are treated as parameters if they are
>>>> explicitly
>>>> declared via declareParameters or if they begin with “:”.
>>>> Names are treated as variable names if they are explicitly declared
>>>> via declareVariables.
>>>> Names are treated as field names if they are either members of
>>>> the candidate class, or they are qualified by the class and can
>>>> be resolved to a static field of that name in the specified class.
>>>> Otherwise, names are treated as implicitly defined variable names.
>>>> </spec>
>>>>
>>>> This then allows access to static fields in *all* classes and
>>>> not just the java.lang classes. So a user can specify
>>>> Integer.MAX_VALUE, MyClass.MY_STATIC_FIELD, java.awt.Color.BLACK
>>>> or whatever and since they are prefixed by the class name, the
>>>> (static) field will be found and can be used.
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Michael Bouschen Tech@Spree Engineering GmbH
>>> mailto:mbo.tech@spree.de http://www.tech.spree.de/
>>> Tel.:++49/30/235 520-33 Buelowstr. 66
>>> Fax.:++49/30/2175 2012 D-10783 Berlin
>>>
>>
>> Craig Russell
>>
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>>
>> 408 276-5638 mailto:Craig.Russell@sun.com
>>
>> P.S. A good JDO? O, Gasp!
>>
>>
>
>
> --
> Michael Bouschen Tech@Spree Engineering GmbH
> mailto:mbo.tech@spree.de http://www.tech.spree.de/
> Tel.:++49/30/235 520-33 Buelowstr. 66
> Fax.:++49/30/2175 2012 D-10783 Berlin
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Clarification needed on class names in query filters
Posted by Michael Bouschen <mb...@spree.de>.
Hi Craig,
[...]
>
>> I like your proposal: "... members of the candidate class, or they
>> are qualified by the class and can be resolved to a static field of
>> that name in the specified class....". Please note this includes that
>> the the class qualifier might be a fully qualified class name. So for
>> a path expression 'a.b.c' the query compiler needs to analyze the
>> entire path expression, before it can decide that 'a' is an implicit
>> variable.
>
>
> I was hoping for a rule that would allow the compiler to determine
> that "a" is a class name not an implicit variable, without using the
> existence of b.c in a to determine it.
The case that 'a' is a class name is easy. The compiler can check if 'a'
is in the the package of the candidate class or is imported. And there
is no need to look at 'b.c' to resolve 'a'.
The analysis gets complicated if 'a' is part of the package name in a
fully qualified class name, e.g. com.xyz.hr.MyClass.MY_STATIC_FIELD.
Here the compiler should not treat 'com' as an implicit variable. But it
needs to analyze 'com.xyz.hr.MyClass' before it can decide that 'com' is
part of a package name.
> Due to the common practice of starting variable names with lower-case
> and classes with upper-case, I think that this is probably a corner case.
For the user this is a corner case, but not for the compiler. It does
not pay attention to common practice of identifier naming :-).
> But I'm still hoping that we can have an unambiguous rule, inserting
> something into the rule below after "names are treated as field names
> if they are members of the candidate class": "Names are treated as a
> class name if it exists in the package of the candidate class or has
> been imported".
This is more clear, but it does not allow fully qualified class names in
a static field access expression. This might be ok, given the fact that
a static field access will not be very common in a JDOQL query. But the
spec should explicitly state this, since this is different in other
parts of JDOQL: you can use a fully qualified class in
variable/parameter declarations or in cast expressions.
Regards Michael
>
> Craig
>
>>
>> Regards Michael
>>
>>> Hi Craig,
>>>
>>>
>>>
>>>> <spec>
>>>> Names in the filter are treated as parameters if they are explicitly
>>>> declared via declareParameters or if they begin with “:”. A14.6.5-4
>>>> [Names are treated as variable names if they are explicitly declared
>>>> via declareVariables. Otherwise, names are treated as field names if
>>>> they are members of the candidate class. Finally, names are treated
>>>> as implicitly defined variable names.]
>>>> </spec>
>>>>
>>>> Any suggestions for improvement?
>>>>
>>>>
>>>>
>>>
>>> How about this :-
>>>
>>> <spec>
>>> Names in the filter are treated as parameters if they are explicitly
>>> declared via declareParameters or if they begin with “:”.
>>> Names are treated as variable names if they are explicitly declared
>>> via declareVariables.
>>> Names are treated as field names if they are either members of the
>>> candidate class, or they are qualified by the class and can be
>>> resolved to a static field of that name in the specified class.
>>> Otherwise, names are treated as implicitly defined variable names.
>>> </spec>
>>>
>>> This then allows access to static fields in *all* classes and not
>>> just the java.lang classes. So a user can specify Integer.MAX_VALUE,
>>> MyClass.MY_STATIC_FIELD, java.awt.Color.BLACK or whatever and since
>>> they are prefixed by the class name, the (static) field will be
>>> found and can be used.
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Michael Bouschen Tech@Spree Engineering GmbH
>> mailto:mbo.tech@spree.de http://www.tech.spree.de/
>> Tel.:++49/30/235 520-33 Buelowstr. 66
>> Fax.:++49/30/2175 2012 D-10783 Berlin
>>
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com
>
> P.S. A good JDO? O, Gasp!
>
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
Re: Clarification needed on class names in query filters
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi,
On Dec 28, 2005, at 2:04 PM, Michael Bouschen wrote:
> Hi Andy,
>
> I agree JDOQL should support accessing static fields of an
> arbitrary class and not just of java.lang classes.
It already does, and this section just hasn't been updated for it.
<spec>
A14.6.2-43 [Identifiers that are persistent field names or public
final static field names are required to be supported by JDO
implementations.] Other identifiers might be supported but are not
required. Thus, portable queries must not use fields other than
persistent or public final static field names in filter expressions.
</spec>
> I like your proposal: "... members of the candidate class, or they
> are qualified by the class and can be resolved to a static field of
> that name in the specified class....". Please note this includes
> that the the class qualifier might be a fully qualified class name.
> So for a path expression 'a.b.c' the query compiler needs to
> analyze the entire path expression, before it can decide that 'a'
> is an implicit variable.
I was hoping for a rule that would allow the compiler to determine
that "a" is a class name not an implicit variable, without using the
existence of b.c in a to determine it. Due to the common practice of
starting variable names with lower-case and classes with upper-case,
I think that this is probably a corner case. But I'm still hoping
that we can have an unambiguous rule, inserting something into the
rule below after "names are treated as field names if they are
members of the candidate class": "Names are treated as a class name
if it exists in the package of the candidate class or has been
imported".
Craig
>
> Regards Michael
>
>> Hi Craig,
>>
>>
>>> <spec>
>>> Names in the filter are treated as parameters if they are explicitly
>>> declared via declareParameters or if they begin with “:”. A14.6.5-4
>>> [Names are treated as variable names if they are explicitly declared
>>> via declareVariables. Otherwise, names are treated as field names if
>>> they are members of the candidate class. Finally, names are treated
>>> as implicitly defined variable names.]
>>> </spec>
>>>
>>> Any suggestions for improvement?
>>>
>>
>> How about this :-
>>
>> <spec>
>> Names in the filter are treated as parameters if they are explicitly
>> declared via declareParameters or if they begin with “:”.
>> Names are treated as variable names if they are explicitly declared
>> via declareVariables.
>> Names are treated as field names if they are either members of the
>> candidate class, or they are qualified by the class and can be
>> resolved to a static field of that name in the specified class.
>> Otherwise, names are treated as implicitly defined variable names.
>> </spec>
>>
>> This then allows access to static fields in *all* classes and not
>> just the java.lang classes. So a user can specify
>> Integer.MAX_VALUE, MyClass.MY_STATIC_FIELD, java.awt.Color.BLACK
>> or whatever and since they are prefixed by the class name, the
>> (static) field will be found and can be used.
>>
>>
>>
>
>
> --
> Michael Bouschen Tech@Spree Engineering GmbH
> mailto:mbo.tech@spree.de http://www.tech.spree.de/
> Tel.:++49/30/235 520-33 Buelowstr. 66
> Fax.:++49/30/2175 2012 D-10783 Berlin
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Clarification needed on class names in query filters
Posted by Michael Bouschen <mb...@spree.de>.
Hi Andy,
I agree JDOQL should support accessing static fields of an arbitrary
class and not just of java.lang classes. I like your proposal: "...
members of the candidate class, or they are qualified by the class and
can be resolved to a static field of that name in the specified
class....". Please note this includes that the the class qualifier might
be a fully qualified class name. So for a path expression 'a.b.c' the
query compiler needs to analyze the entire path expression, before it
can decide that 'a' is an implicit variable.
Regards Michael
>Hi Craig,
>
>
>
>><spec>
>>Names in the filter are treated as parameters if they are explicitly
>>declared via declareParameters or if they begin with “:”. A14.6.5-4
>>[Names are treated as variable names if they are explicitly declared
>>via declareVariables. Otherwise, names are treated as field names if
>>they are members of the candidate class. Finally, names are treated
>>as implicitly defined variable names.]
>></spec>
>>
>>Any suggestions for improvement?
>>
>>
>
>How about this :-
>
><spec>
>Names in the filter are treated as parameters if they are explicitly
>declared via declareParameters or if they begin with “:”.
>Names are treated as variable names if they are explicitly declared
>via declareVariables.
>Names are treated as field names if they are either members of the candidate
>class, or they are qualified by the class and can be resolved to a static
>field of that name in the specified class.
>Otherwise, names are treated as implicitly defined variable names.
></spec>
>
>This then allows access to static fields in *all* classes and not just the
>java.lang classes. So a user can specify Integer.MAX_VALUE,
>MyClass.MY_STATIC_FIELD, java.awt.Color.BLACK or whatever and since they are
>prefixed by the class name, the (static) field will be found and can be used.
>
>
>
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
Re: Clarification needed on class names in query filters
Posted by Andy Jefferson <an...@jpox.org>.
Hi Craig,
> <spec>
> Names in the filter are treated as parameters if they are explicitly
> declared via declareParameters or if they begin with “:”. A14.6.5-4
> [Names are treated as variable names if they are explicitly declared
> via declareVariables. Otherwise, names are treated as field names if
> they are members of the candidate class. Finally, names are treated
> as implicitly defined variable names.]
> </spec>
>
> Any suggestions for improvement?
How about this :-
<spec>
Names in the filter are treated as parameters if they are explicitly
declared via declareParameters or if they begin with “:”.
Names are treated as variable names if they are explicitly declared
via declareVariables.
Names are treated as field names if they are either members of the candidate
class, or they are qualified by the class and can be resolved to a static
field of that name in the specified class.
Otherwise, names are treated as implicitly defined variable names.
</spec>
This then allows access to static fields in *all* classes and not just the
java.lang classes. So a user can specify Integer.MAX_VALUE,
MyClass.MY_STATIC_FIELD, java.awt.Color.BLACK or whatever and since they are
prefixed by the class name, the (static) field will be found and can be used.
--
Andy
Java Persistent Objects - JPOX
Re: Clarification needed on class names in query filters
Posted by Bin Sun <su...@yahoo.com>.
I think there should be a priority list, reguarding to
both java.lang classes and user classes. The only
difference is that a Query implicitly declares
importing 'java.lang.*' at creation.
If more strict, these quotes like 'Integer.MAX_VALUE'
are forbidden, and parameters are used instead. This
mostly prevents java.lang classes from appearing in
the filter.
--- Craig L Russell <Cr...@Sun.COM> wrote:
> Javadogs,
>
> The section in 14.6.5 is incomplete. It doesn't
> address names that
> are class names, as in Integer.MAX_VALUE. According
> to the following,
> Integer will be treated as an implicitly defined
> variable name. :-(
>
> <spec>
> Names in the filter are treated as parameters if
> they are explicitly
> declared via declareParameters or if they begin with
> ?? A14.6.5-4
> [Names are treated as variable names if they are
> explicitly declared
> via declareVariables. Otherwise, names are treated
> as field names if
> they are members of the candidate class. Finally,
> names are treated
> as implicitly defined variable names.]
> </spec>
>
> Any suggestions for improvement?
>
> Thanks,
>
> Craig
>
> Craig Russell
> Architect, Sun Java Enterprise System
> http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
__________________________________________
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com