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 Thu, 29 Dec 2005 23:10:15 GMT
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			


Mime
View raw message