db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bin Sun <sun2...@yahoo.com>
Subject Re: Clarification needed on class names in query filters
Date Wed, 04 Jan 2006 02:07:47 GMT
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 


Mime
View raw message