Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 14908 invoked from network); 4 Jan 2006 06:06:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 Jan 2006 06:06:33 -0000 Received: (qmail 99173 invoked by uid 500); 4 Jan 2006 06:06:33 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Received: (qmail 99161 invoked by uid 99); 4 Jan 2006 06:06:33 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jan 2006 22:06:33 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [192.18.98.34] (HELO brmea-mail-3.sun.com) (192.18.98.34) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jan 2006 22:06:31 -0800 Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k0466A3F012221 for ; Tue, 3 Jan 2006 23:06:10 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ISK006010C8CC00@mail-amer.sun.com> (original mail from Craig.Russell@Sun.COM) for jdo-dev@db.apache.org; Tue, 03 Jan 2006 23:06:10 -0700 (MST) Received: from [192.168.0.10] (c-24-6-172-77.hsd1.ca.comcast.net [24.6.172.77]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ISK00KLR0Y8AA30@mail-amer.sun.com> for jdo-dev@db.apache.org; Tue, 03 Jan 2006 23:06:10 -0700 (MST) Date: Tue, 03 Jan 2006 22:06:05 -0800 From: Craig L Russell Subject: Re: Clarification needed on class names in query filters In-reply-to: <20060104020747.40230.qmail@web51009.mail.yahoo.com> Sender: Craig.Russell@Sun.COM To: Apache JDO project , JDO Expert Group Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.746.2) Content-type: multipart/signed; protocol="application/pkcs7-signature"; boundary=Apple-Mail-334--866222911; micalg=sha1 References: <20060104020747.40230.qmail@web51009.mail.yahoo.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --Apple-Mail-334--866222911 Content-Type: multipart/alternative; boundary=Apple-Mail-333--866224191 --Apple-Mail-333--866224191 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; format=flowed 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? > > --- Craig L Russell 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, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Names in the filter are treated as >> parameters if they are >>>>>>>>>>> explicitly >>>>>>>>>>> declared via declareParameters or if they >> begin with ?? >>>>>>>>>>> A14.6.5-4 >> > =3D=3D=3D message truncated =3D=3D=3D > > > > =09 > __________________________________________ > Yahoo! DSL =96 Something to write home about. > Just $16.99/mo. or less. > dsl.yahoo.com > 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! --Apple-Mail-333--866224191 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 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!

=A0 =A0 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 =A0
explicitly declared via = declareParameters or if
they = begin with ??
Names = are treated as variable names if they are
explicitly declared =A0
via declareVariables.
Names are treated as field or property names = if
they are fields or =A0
properties of the candidate = class.
Names are treated as class names = if they exist in
the package = of =A0
the candidate class or have been = imported.
or if they = are in the java.lang package. e.g.
Integer. [we = did this =A0
in other places.]


=
Names are treated as = package names if they are
part of = the package =A0
=
qualifier of a class name = in a static field

Otherwise, names are treated as implicitly = defined
variable = names.


In a dot expression the left to the dot = determines
the context = for =A0
the evaluation of the name to = the right of the
dot. This = name is =A0
=
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 =A0
name bit that = you identified below? For some
=
reason, I'm having =A0
a hard time = with it.

sure, I will try to rewrite.



=
But I would like clarify first = whether JDOQL
should support fully =A0
qualified class names in static field access = or
not. So = is the =A0
=
following expression = legal:
=A0this.field > = com.xyz.hr.MyClass.MY_STATIC_FIELD
or should it = be
=A0this.field > = MyClass.MY_STATIC_FIELD
with MyClass = being imported.


Either should work.


=
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 =A0
they are qualified by the class and can be
=
resolved to a =A0
static field of that name in the specified
=
class....". Please =A0
note this includes that the the class
=
qualifier might be a =A0
fully qualified class name. So for a path
=
expression 'a.b.c' =A0
the query compiler needs to analyze the
=
entire path =A0
expression, before it can decide that 'a' is
=
an implicit =A0
variable.




I was = hoping for a rule that would allow the
=
compiler to =A0
determine = that "a" is a class name not an
=
implicit variable, =A0
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 =A0
check if 'a' is in the the package of the
=
candidate class or is =A0
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 =A0
name in a fully qualified class name, e.g. =A0
compiler should =A0
not treat 'com' as an implicit variable. But
=
it needs to =A0
analyze 'com.xyz.hr.MyClass' before it can
=
decide that 'com' is =A0
part of a package name.

Due to the common practice of starting
=
variable names with =A0
lower-case = and classes with upper-case, I
=
think that this is =A0
probably a = corner case.



For the = user this is a corner case, but not
=
for the compiler. =A0
It does not pay attention to common practice
=
of identifier =A0
naming :-).

But I'm = still hoping that we can have an
=
unambiguous rule, =A0
inserting = something into the rule below after
=
"names are =A0
treated as = field names if they are members of
=
the candidate =A0
class":=A0 "Names are treated as a class = name
=
if it exists in =A0
the package = of the candidate class or has
=
been imported".



This is more clear, but it does = not allow
=
fully qualified class =A0
names in a static field access expression.
=
This might be ok, =A0
given the fact that a static field access will
=
not be very =A0
common in a JDOQL query. But the spec should
=
explicitly state =A0
this, since this is different in other parts
=
of JDOQL: you can =A0
use a fully qualified class in
=
variable/parameter declarations =A0
or in cast expressions.

Regards = Michael

=
Craig


Regards Michael

Hi = Craig,


<spec>
Names in the filter are treated as
=
=A0
explicitly
declared via = declareParameters or if they
=
begin = with ?? =A0
=
A14.6.5-4
=

=3D=3D=3D = message truncated =3D=3D=3D




=A0
Yahoo! = DSL =96 Something to write home about.=A0
Just = $16.99/mo. or less.=A0
=A0

=

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!


= --Apple-Mail-333--866224191-- --Apple-Mail-334--866222911 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHjCCAtcw ggJAoAMCAQICAw3FWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwMTEwMDA0MTA5WhcNMDYwMTEwMDA0MTA5WjBHMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSQwIgYJKoZIhvcNAQkBFhVDcmFpZy5SdXNzZWxsQFN1 bi5DT00wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDti7ZE4rO6oXKbLM02AG9WY55t udmBVL53fb3V3X5S1kvcJOk1NEMIYT/T7Ww+/hE955zvHT29+mIoNe8AW/yj1WUH8uGG2HxhwCHI UQTHmN/ioVJgjwUaYbtNMKbL/NRpnL0QWewdMJS+6IFzFyX7ADFW5cJ+UWNLvNeWAQtN0mtLildn vdOgh50i8YPvACNkCHoomGjXx0azcXbe1X3c5AgRI6e2CZe5k2lRFQFUMqkjdoMtQPoNqJ1BxH9l i4cnabl8mcTwHHl44hrvb8ThqwRf2pfJh2vVuwmgK6z4IWjOk4RQM+0ODsRdq67mBdimJYmPMK1p RMBHzrUsfKxNAgMBAAGjMjAwMCAGA1UdEQQZMBeBFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTAMBgNV HRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIj86LzxCHedStDLMEeqHLy+UFG7zIRHfChSIV42 +MvXicydXEBh8v0Ry1V2d/lY4jS78G5yW5R9fKt1U5nlRBCOVzdhomvSolnNRIT71wPVVDrAIVlA YpXKxSmVBq7+4hV+3ZLHDeq3qZnNmiJR0sTEUD16xZX1RJs9dRYPCHoRMIIDPzCCAqigAwIBAgIB DTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29t MB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbL rzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZ cmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0 cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQD AgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0B AQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3h YWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1 TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMNxVkwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwMTA0MDYwNjA2WjAjBgkqhkiG9w0BCQQxFgQU qW6CpFbr1UXUW84iglIt1Uw2NaUweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw3FWTB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMNxVkwDQYJKoZIhvcNAQEBBQAEggEA 1Ma1R0v2z6rBO3sdPgtmA9QxKNRXFS+JSOh81pktVBr52ys3jguxnmU/hELTkZuMQDRZlemzFMQS mXb0sIXSi+cy8vBXYaAxlRQ7CnaXPLn1kfMerIR9bx84wuoggeK1VHmzq621gmn0LxX7Fn3+Swk+ V8g0bQYmQWGoWhJqEKE0xz6I9CWYlNjKydriD6khDgN7ebl3gLHiQlAvlgscjpP7X/TYyLXQt/oZ wkdgLE7uGnk6T5nnntFmyQzRkdhB1sYsNTgDtu/RTO1zYfKIwtIU7i3icnTVnBrUkkk5pZzgqv5e RxRvQ9gymXtztpZ7YrguatxAgs/okqvD5aTmdgAAAAAAAA== --Apple-Mail-334--866222911--