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 [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
--
Michael Bouschen [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
--
Michael Bouschen [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
