RE: [sv-ec] RE: [sv-bc] Resolving name resolution

I support this idea. I already suggested this for 1858. 
This adds new capability that the language is currently 
missing. If a class field has the same name as a global 
symbol, there is no way to refer to the global symbol 
from inside the class unless it is in a package.

> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On 
> Behalf Of Jonathan Bromley
> 
> I have been trying hard to follow these discussions, and I'm 
> quite sure there are parts that have gone over my head; so, 
> if I now show some naivety, I hope I can be forgiven.
> 
> It seems to me that - particularly in the last two emails 
> from Gord and Mark - the dominant problem is: 
> when does a name resolve through "this." (or, in the case of 
> inline constraints, "item.") and when does it resolve outside 
> the class of interest?  The answer to this question can be 
> affected by code that is very, very far from the point of 
> use, and which might change in an arbitrary and unpredictable 
> way in the future.
> 
> From a user's point of view I absolutely agree that this is a 
> problem.  It is much too easy to write code that unwittingly 
> falls foul of this.  In particular, if I make reference from 
> inside a class to a name in the environment, I would very 
> much like to be able to force that reference to bind outside 
> the class, just in case someone modifies the parent class in 
> some way so that the binding might unexpectedly change.  As 
> Gord has pointed out, it is not always possible or 
> practicable to point the name explicitly at somewhere outside 
> the class, since it might be something that has no 
> hierarchical reference.
> 
> We can force a name to bind *inside* the class by using 
> "super." or "this." but we have no explicit way to push the 
> binding *outside*.  Is it worth exploring such a possibility 
> - some syntax that would have no effect except to suppress 
> the implicit "this." prefix of names referenced from within a class?  
> The use of :: as a prefix springs to mind.
> 
> If we had *both* these options - explicit "this." and 
> explicit "never-this." - it would become reasonable for tools 
> to issue warnings in potentially ambiguous cases.
> A "never-this." prefix would also make it possible to get 
> round the current absurdity of inline constraints whereby a 
> name in the target class can irrevocably hide a name in the 
> local scope.
> 
> I'm sure this doesn't cover all the concerns, but it's a 
> change that would help me to deal with many of the situations 
> that Gord and Mark have been discussing, and I'm fairly sure 
> it could be done without breaking backwards compatibility.
> --
> Jonathan Bromley, Consultant
> 
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
> 
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, 
> Hampshire, BH24 1AW, UK
> Tel: +44 (0)1425 471223                   Email: 
> jonathan.bromley@doulos.com
> Fax: +44 (0)1425 471573                           Web: 
> http://www.doulos.com
> 
> The contents of this message may contain personal views which 
> are not the views of Doulos Ltd., unless specifically stated.
> 
> --
> This message has been scanned for viruses and dangerous 
> content by MailScanner, and is believed to be clean.
> 
> 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.