[sv-ec] RE: 1858 local:: proposal uploaded

From: Arturo Salz <Arturo.Salz_at_.....>
Date: Tue Dec 11 2007 - 09:27:33 PST
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