I am ok with Jonathan's suggestion as a starting point. Explicit naming solves issues in terms of one's ability to direct resolution. I still have concerns about just having the ambiguous cases be warnings. Such warnings would occur very early on, before components are "shipped". I'd much rather have the truly unknown cases be illegal, particularly due to the two kinds of errors I talked about in my previous email (surprising capture and latent errors). In such cases, which are determinable at compile, the user should be required to define the direction of resolution (inward or outward). This would apply to both inherited members from opaque base types and inline constraints. We would also have to be very careful about exactly how far "outward" things bind, particularly in view of nested classes and static member inheritance from opaque types. Using "this." or "item." for an inwards binding is reasonable, but having a direct prefix for "outward" is more touchy. For example: module m #(type T = int, type T2 = int); int x; class C extends T; class D extends T2; function int get_x(); return x; endfunction endclass endclass endmodule If "x" is a static member inherited by C from T, then a simple "outer" from D would likely still not be quite what we want (or at least not what I want). What I am after is "bind x to the statically visible x". If that is what we decide "::x" or similar would mean, that would be Ok. I think that we could then differentiate between: this.x // asserts that "x" is in D C::x // asserts that "x" is in C (must be static) ::x // asserts that "x" is the nearest "statically bound" x I definitely think that permitting a bare "x" in a context like "get_x" is a bad idea. If "x" is not immediately visible in "D" at compile, user disambiguation should be required. Gord Mark Hartoog wrote: > 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. >> >> >> -- -------------------------------------------------------------------- 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 Fri Sep 7 15:09:11 2007
This archive was generated by hypermail 2.1.8 : Fri Sep 07 2007 - 15:09:42 PDT