|
Home > Archive > Apache JDO Project > January 2006 > Clarification needed on class names in query filters
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Clarification needed on class names in query filters
|
|
| Craig L Russell 2005-12-26, 5:45 pm |
| | |
| Bin Sun 2005-12-27, 5:45 pm |
| I think there should be a priority list, reguarding to
both java.lang classes and user classes. The only
difference is that a Query implicitly declares
importing 'java.lang.*' at creation.
If more strict, these quotes like 'Integer.MAX_VALUE'
are forbidden, and parameters are used instead. This
mostly prevents java.lang classes from appearing in
the filter.
--- Craig L Russell <Craig.Russell@Sun.COM> wrote:
> Javadogs,
>
> The section in 14.6.5 is incomplete. It doesn't
> address names that
> are class names, as in Integer.MAX_VALUE. According
> to the following,
> Integer will be treated as an implicitly defined
> variable name. :-(
>
> <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?
>
> Thanks,
>
> Craig
>
> 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!
>
>
________________________________________
__
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
| |
| Andy Jefferson 2005-12-27, 5:46 pm |
| Hi Craig,
> <spec>
> Names in the filter are treated as parameters if they are explicitly
> declared via declareParameters or if they begin with =E2=80=9C:=E2=80=9D.=
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 =E2=80=9C:=E2=80=9D.
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 candidat=
e=20
class, or they are qualified by the class and can be resolved to a static=20
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=
=20
java.lang classes. So a user can specify Integer.MAX_VALUE,=20
MyClass.MY_STATIC_FIELD, java.awt.Color.BLACK or whatever and since they ar=
e=20
prefixed by the class name, the (static) field will be found and can be use=
d.
=2D-=20
Andy
Java Persistent Objects - JPOX
| |
| Michael Bouschen 2005-12-28, 5:46 pm |
| Hi Andy,
I agree JDOQL should support accessing static fields of an arbitrary
class and not just of java.lang classes. 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.
Regards Michael
>Hi Craig,
>
>
>
>
>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 L Russell 2005-12-28, 5:46 pm |
| | |
| Michael Bouschen 2005-12-29, 5:46 pm |
| Hi Craig,
[...]
>
>
>
> 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
>
>
> 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 L Russell 2005-12-29, 5:46 pm |
| | |
| Michael Bouschen 2005-12-29, 5:46 pm |
| 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:
>
>
> 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 L Russell 2005-12-29, 5:46 pm |
| | |
| Michael Bouschen 2006-01-03, 5:46 pm |
| 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:
>
>
>
> Thanks.
>
>
>
> Either should work.
>
> Craig
>
>
> 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 L Russell 2006-01-03, 5:46 pm |
| | |
| Bin Sun 2006-01-03, 8:45 pm |
| 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:
>
> they are
> they begin with ??
> explicitly declared
> they are fields or
> the package of
> or if they are in the java.lang package. e.g.
> Integer. [we did this
> in other places.]
>
> Craig
>
> part of the package
> access.
> variable names.
> the context for
> dot. This name is
> wrote:
> including the class
> reason, I'm having
> should support fully
> not. So is the
> wrote:
> candidate class, or
> resolved to a
> class....". Please
> qualifier might be a
> expression 'a.b.c'
> entire path
> an implicit
> compiler to
> implicit variable,
> determine it.
> compiler can
> candidate class or is
> 'b.c' to resolve 'a'.
> of the package
> compiler should
> it needs to
> decide that 'com' is
> variable names with
> think that this is
> for the compiler.
> of identifier
> unambiguous rule,
> "names are
> the candidate
> if it exists in
> been imported".
> fully qualified class
> This might be ok,
> not be very
> explicitly state
> of JDOQL: you can
> variable/parameter declarations
> parameters if they are
> begin with ??
>
=== message truncated ===
________________________________________
__
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
| |
| Craig L Russell 2006-01-04, 2:45 am |
| |
|
|
|
|