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

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.