Hi!
Excuse me, but I can't see implicit variable
declaration in this proposal. Am I missing something?
--- Craig L Russell <[EMAIL PROTECTED]> 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
