Re: [sv-ec]E-mail Vote: Closes 12am PST December 15 2007

Mark Hartoog wrote:
> But this is consistent with the no back tracking rule for variables 
> in dotted names. Once the first name matches a variable, we never
> back track and keep searching for another match for the whole dotted
> name.
> 
> Are you arguing that "this" should be treated differently than a normal
> variable in dotted names? We should continue searching other
> scopes for a different "this" that could resolve the whole name?
> 
> I don't feel strongly one way or the other, but I just think what 
> is in Arturo's proposal is more consistent with the no back tracking
> rule for variables in dotted names. If you want to access the class
> method 'this' you can use "local::this.x" which should be the same as
> "local::x" unless you also have a 'x' variable in the method.


I addressed that aspect earlier -- "this" is special in that it
is the "object on which the method is invoked".  The fact is that
"this.x" is (normally) just a pseudonym for "x" if "x" is a
member of the class.  The interpretation that you and Arturo
are suggesting changes that natural expectation but ONLY
in the context of an inline constraint -- which is also the only
place in which "this" could conceivably have two meanings.
Since "x" can go either way, I believe that it would be
much more surprising to find that it can't.

Normal structs, etc. are different in that the prefix is
never implicit so there is no question about what is going
on.  I absolutely would agree that in an inline constraint,
if you have "a.b.c" and "a" matches in the target object,
you are committed.  However, I would also expect that if there
were no "a" in the target that "a.b.c" and "this.a.b.c" would
be equivalent (as they would be in the calling context) and
that is weakened by the given proposal.

Gord.
-- 
--------------------------------------------------------------------
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.