db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Bouschen <mbo.t...@spree.de>
Subject Re: Clarification needed on class names in query filters
Date Tue, 03 Jan 2006 23:03:06 GMT
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			


Mime
View raw message