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 Wed, 04 Jan 2006 06:06:05 GMT
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 <Craig.Russell@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!


Mime
View raw message