| 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?
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
|
smime.p7s