I agree with Dave, the base class is visible through the class inheritance of p3. Francoise ' -----Original Message----- From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Rich, Dave Sent: Monday, September 11, 2006 2:06 PM To: Arturo Salz; Vreugdenhil, Gordon Cc: Logie Ramachandran; Mark Hartoog; SV_BC List; SV_EC List; sv-ac@verilog.org Subject: RE: [sv-ec] Re: [sv-bc] Name resolution and imports I might disagree that is not legal. Class p3 will get access to the symbols via the class hierarchy mechanism. It does not need to go through the package. Dave > -----Original Message----- > From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On > Behalf Of Arturo Salz > Sent: Monday, September 11, 2006 11:00 AM > To: Vreugdenhil, Gordon; Arturo Salz > Cc: Logie Ramachandran; Mark Hartoog; SV_BC List; SV_EC List; sv- > ac@server.verilog.org > Subject: RE: [sv-ec] Re: [sv-bc] Name resolution and imports > > You are correct in that simple case, but, consider the following example > > package p1; > class base; > int x; > virtual function void F(base x); ... endfunction > endclass > endpackage > > package p2; > class derived extends p1::base; > int y; > endclass > endpackage > > module top; > import p2::*; > > class p3 extends derived; > virtual function void F(base x); // this is not legal > without the re-import > ... > endfunction > > ... > endmdodule > > In this case, the base class is not visible to the importing scope > without explicitly importing package p1. Or is it? Why should end-users > need to add an explicit import of p1 (import p1::*) or explicitly write > (p1::base)? > > Arturo > > -----Original Message----- > From: Gordon Vreugdenhil [mailto:gordonv@model.com] > Sent: Monday, September 11, 2006 10:50 AM > To: Arturo Salz > Cc: Logie Ramachandran; Mark Hartoog; SV_BC List; SV_EC List; > sv-ac@verilog.org > Subject: Re: [sv-ec] Re: [sv-bc] Name resolution and imports > > > > Arturo Salz wrote: > > > Hi Gord, > > > > I believe you missed the point that Logie was trying to make. His > point > > is that C++ users have access to libraries. In SystemVerilog, the > > closest thing to a C library is a package. And while it is true that a > > #include defines the symbols to the compiler, users do not need to be > > aware from which library the symbols will ultimately be imported. This > > is the benefit that re-importing identifiers from a package will add. > In > > particular I'm thinking of this scenario: a package "A" defines a > class > > that is subsequently extended by package "B". Then, the end-user > should > > only be required to import package "B" to have full access to the > class, > > otherwise packages will be largely useless as re-usable items. I > believe > > there's no disagreement as to the benefit of re-imported identifiers, > > the only issue is what should be the mechanism for allowing them. > > > But that isn't an issue. > > If you have: > package p1; > class base; > int x; > endclass > endpackage > > package p2; > import p1::*; > class derived extends base; > int y; > endclass > endpackage > > module top; > import p2::*; > derived d = new; > > initial begin d.x = 1; d.y = 2; end > > endmdodule > > There is absolutely no requirement for "top" in import p1 unless the > user wanted to *declare* something of type p1::base. > > Gord. > > > > > > Arturo > > > > -----Original Message----- > > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of > > Gordon Vreugdenhil > > Sent: Monday, September 11, 2006 8:51 AM > > To: Logie Ramachandran > > Cc: Mark Hartoog; SV_BC List; SV_EC List; sv-ac@verilog.org > > Subject: [sv-ec] Re: [sv-bc] Name resolution and imports > > > > > > > > Logie Ramachandran wrote: > > > > > >>Hi Gordon, > >> > > > > [...] > > > >>If you look at a C++ example, users are expected to #include > >>"systemc.h". Users need not worry about the explicit dependencies of > >>"systemc.h". No one worries about what #include statements are > >>found in "systemc.h". > >>I think this should be analogous for SV packages. > > > > > > > > I think you are confusing include and import. > > > > Please take a look at C++ "use" of a namespace. That is what should > > be analogous to an SV import (and is analogous to a VHDL use). > > > > The intent and mechanism of an import and an include are very > > different; trying to think of them in the same manner is not the > > right approach. > > > > Gord. > > > > > > > >>Thanks > >> > >>Logie. > >> > >> > >>-----Original Message----- > >>From: Gordon Vreugdenhil [mailto:gordonv@model.com] > >>Sent: Monday, September 11, 2006 7:55 AM > >>To: Logie Ramachandran > >>Cc: Mark Hartoog; SV_BC List; SV_EC List; sv-ac@verilog.org > >>Subject: Re: [sv-bc] Name resolution and imports > >> > >> > >>There is a difference between *interface* and *implementation*. > >> > >>Your assumption is that everything needed for *implementation* > >>should be exposed in the *interface*. That makes for substantial > >>problems downstream in large designs since names will tend to "leak" > >>through and cause downstream things to break. > >> > >>I do think that there needs to be a mechanism for *explicitly* > >>forwarding a definition through a package which *explicitly* makes > >>it part of the "interface" to the package, but doing that by default > >>is going to be chaotic. > >> > >>"typedef" already gives us that mechanism for types; it would be > >>trivial to do something similar for other declarations. > >> > >>Alternatively, I might consider a "local" import which doesn't have > >>the troublesome behavior. I do feel very strongly that maintaining > >>a distinction between the interface and implementation is crucial. > >> > >>One can always come up with examples for which either default seems > >>best. Given that C++ and VHDL have opted for the more restrictive > >>default behavior, it also seems more consistent from a > >>methodological standpoint to retain consistency. > >> > >>Gord. > >> > >> > >> > >>Logie Ramachandran wrote: > >> > >> > >>>Hi Mark, > >>> > >>>Thanks for providing the example. For the purposes of this discussion > >>>it would be good to separate out three different kinds of users. > >>> > >>>1) Base package providers - could be coming from external > >>> methodology groups > >>>2) IP provider - independent third party IP provider > >>>3) End user - intending to use the IPs. > >>> > >>>In your example the first package "mytypes" could be coming from > >>>(1), the second packaage could be coming from an IP vendor (2) and > >>>the module code is written by end user. > >>> > >>>The IP provider could potentially uses multiple packages > >> > >>>from various sources to build his/her IP. The assumption here is > >> > >>>that the IP provider is amenable to carefully importing the items > >>>that are necessary for the functioning of the IP. > >>>import 48bitPackage::type48bit; > >>>import 36bitPackage::type36bit; > >>> > >>>However the end user typically does not want to be saddled with all > >>>the packages that the IP vendor used. The end user should be able > >>>to do a "single import statement" (e.g. import IP::*) and interact > >>>with the IP. > >>> > >>>I think it is a big disadvantage if end users have to worry about > >>>and become knowledgeable about all the packages that the IP vendors > >>>use. > >>> > >>>Thanks > >>> > >>>Logie. > >>> > >>> > >>>-----Original Message----- > >>>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of > >> > >>Mark > >> > >> > >>>Hartoog > >>>Sent: Saturday, September 09, 2006 1:02 PM > >>>To: Gordon Vreugdenhil; SV_BC List; SV_EC List; sv-ac@verilog.org > >>>Subject: RE: [sv-bc] Name resolution and imports > >>> > >>>I have been very busy and not able to comment on this discussion. > >>> > >>>Several objects have been raised about chaining of package imports. > >> > >>One > >> > >> > >>>issue is pollution of the name space. I think name space pollution > >>>created by wild card package imports is a problem with System > Verilog, > >>>but I believe package import chaining reduces name space pollution, > >>>because it gives package developers the tools to do something about > >> > >>this > >> > >> > >>>problem. My assumption is that most Verilog writers will be using > >>>wildcard imports. Consider this example without package import > >> > >>chaining: > >> > >> > >>>package mytypes; > >>> typedef int myint; > >>>endpackage > >>> > >>>package mystuff; > >>> import mytypes::*; > >>> function myint myfunc(); > >>> return 0; > >>> endfunction > >>>endpackage > >>> > >>> > >>>module mycode(); > >>>import mytypes::*; > >>>import mystuff::*; > >>>myint x; > >>>initial x = myfunc(); > >>>endmodule > >>> > >>>I am assuming here that most engineers will just use wildcard imports > >> > >>on > >> > >> > >>>all packages. Because the author of the mycode module was not sure > >> > >>what > >> > >> > >>>types he might need from the mytypes package in order to use the > >>>functions from mystuff, he just wildcard imported all of them. If > >> > >>latter > >> > >> > >>>on, other types are added to the mytypes package, then they will be > >>>available for import into mycode. > >>> > >>>On the other hand, with package chaining, mycode could be written: > >>> > >>>module mycode(); > >>>import mystuff::*; > >>>myint x; > >>>initial x = myfunc(); > >>>endmodule > >>> > >>>Now only the symbols from mytypes that are actually used in mystuff > >> > >>are > >> > >> > >>>available for import into mycode. If someone adds another type in > >>>mytypes that has nothing to do with mystuff, it is not available for > >>>import into mycode. > >>> > >>>I would also add that it is much more likely that the people writing > >>>packages can be trained to worry about the dangers of wildcard > imports > >>>then it would be to train all engineers to worry about this. I expect > >>>most engineers will be using wildcard imports because that is the > >>>easiest thing to do. > >>> > >>>Another issue about chaining is that it creates alias names, and I > >> > >>guess > >> > >> > >>>people consider that objectionable. I don't understand this argument, > >>>since System Verilog is already full of aliases. Typedefs and type > >>>parameters create aliases for type names already. In fact, package > >>>mystuff could just say: > >>> > >>>typedef mytypes::myint myint; > >>> > >>>and then it could be written without any import statement. Chaining > of > >>>package imports is no different then writing the package like this. > >>> > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf > >>>>Of Gordon Vreugdenhil > >>>>Sent: Thursday, August 31, 2006 10:03 AM > >>>>To: SV_BC List; SV_EC List; sv-ac@verilog.org > >>>>Subject: [sv-bc] Name resolution and imports > >>>> > >>>>All, > >>>> > >>>>The name resolution working group has encountered an issue that > >>>>needs to be resolved at the committee level. The issue is > >>>>directly addressed by Mantis 1323 -- "are imported names visible > >>>>to hierarchical references". Mentor and Cadence have both taken > >>>>the position that they are not; Synopsys has taken the position > >>>>that they are. This needs to be resolved quickly as > >>>>implementations have (and will continue) to diverge. This also > >>>>impacts the issue of chained imports (is a symbol imported into a > >>>>package available for import) which is also addressed by Mantis > >>>>1323. > >>>> > >>>>This issue has a direct bearing on back-annotation, pli, and > >>>>related issues since it impacts what the system must present as > >>>>members of a scope and whether hierarchical names for items in a > >>>>design are unique or not. > >>>> > >>>>Currently Mantis 1323 is listed as a BC issue. I'd like to have > >>>>this issue be resolved asap due to the overall impact of the > >>>>interpretation differences. > >>>> > >>>>Question: should this immediately be elevated to the champions > >>>>level or is it appropriate to leave for SV-BC? > >>>> > >>>>Independent of that decision, it would be worthwhile for people to > >>>>speak to this from various perspectives so that we can make an > >>>>informed decision. > >>>> > >>>>Gord > >>>>-- > >>>>-------------------------------------------------------------------- > >>>>Gordon Vreugdenhil 503-685-0808 > >>>>Model Technology (Mentor Graphics) gordonv@model.com > >>>> > >>>> > >>> > >>> > > > > -- > -------------------------------------------------------------------- > Gordon Vreugdenhil 503-685-0808 > Model Technology (Mentor Graphics) gordonv@model.comReceived on Mon Sep 11 11:10:23 2006
This archive was generated by hypermail 2.1.8 : Mon Sep 11 2006 - 11:10:29 PDT