Gord, Some comments inlined below. If we agree to what I propose we can plan merging the proposals. Arturo -----Original Message----- From: Gordon Vreugdenhil [mailto:gordonv@model.com] Sent: Tuesday, December 11, 2007 7:33 AM To: Arturo Salz Cc: SV-EC; Mehdi Mohtashemi; Neil.Korpusik@Sun.com Subject: Re: 1858 local:: proposal uploaded Arturo, I find the repeating of various rules in your proposal to reduce clarity since it isn't clear that you are saying "just do local binding". Are you Ok with the wording that I proposed for that aspect in my proposal? I haven't studied your proposal - only glanced at it. I wrote mine before I saw yours. I believe you're proposing the parenthesis form to guide name binding, and I'm not sure there was consensus for that. In particular you have: Within the in-line constraint, the following rules apply: - Names qualified by this (i.e., this.a) shall bind to the randomize()...with object class. - Names qualified by local:: shall bind to the scope containing the randomize method call. - As it pertains to wildcard package inports, the syntactic form local::a shall be semantically identical to the unqualified name a declared in the local scope. - For method call obj.randomize,() with ... the qualified name local::obj shall bind to the randomize()...with object class. - Unqualified names may bind to either the randomize()...with object class or to the local scope, in that order. But all of that is implied by just the earlier statement: When applied to an identifier within an in-line constraint, the local:: qualifier bypasses the scope of the (randomize()...with object) class and resolves the identifier in the local scope. I agree that the rules above do not contradict the earlier statements. But, I do believe they help summarize things, particularly: - this.foo forces foo to bind into the randomize-with object - if foo is not a property of the object, it is an error. - local::foo forces foo to bind into the local scope of the call. - local::obj.foo is semantically identical to this.foo (and to the less safe unadorned foo). I think that having these there are useful. Perhaps I can change the introductory wording From: Within the in-line constraint, the following rules apply: to: Given the earlier rules, the following rules can be deduced: And, move the third bullet outside since that's a normative statement and it's not clear that it can be deduced. Although I prefer "scope containing the inline constraint declaration" to "local scope". I believe I defined earlier, but I have no problem changing that. In addition, the third point in your list is incorrect -- local::a is the same as a *reference* in the scope containing the inline constraint declaration, not a *declaration* within that scope. Good point. I'll change declaration to reference. I'd strongly prefer to not have any of those rules points present since I think that it then appears that special rules are in play rather than just the normal rules. Finally, your A.8.4 change appears to have a cut-and-paste error since the "FROM" part contains the "local::" text as well. Yup. You're right (actually reverse cut-and-paste). I'll change that. Gord Arturo Salz wrote: > I have uploaded my proposal for the local:: resolution to Mantis item > 1858. The proposal is called 1858-local.pdf. > > > > Arturo > > > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Dec 12 17:05:41 2007
This archive was generated by hypermail 2.1.8 : Wed Dec 12 2007 - 17:06:26 PST