db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Clarification needed on class names in query filters
Date Tue, 03 Jan 2006 23:38:42 GMT
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!


Mime
View raw message