> -----Original Message----- > From: Rich, Dave [mailto:Dave_Rich@mentor.com] > > I think of a parameterized class in SV as a template class in > C++; it's a different kind of beast. > > There are enough problems with parameterized classes that > this kind of change is justified. I strongly disagree and find this statement rather disturbing. Almost all of the issues with classes are because of extensions beyond what was clearly intended in P1800-2005. Many of these extensions have merit and are good ideas on their own, but the committee has to look at these extensions and the issues created by them and decide whether they want to add these extensions to the language at this time. I am particularly thinking about the extension to allow type parameters to be used on the left hand side of the "::" scope resolution operator and extending classes from typedefs and type parameters. Section 8.22 Class scope resolution operator :: says: <LRM>The left operand of the scope resolution operator :: shall be a class name, package name (see 25.2), covergroup type name, coverpoint name or cross name.</LRM> Section 3.10.1 Compilation units says that $unit can also be used with this operator. I think it is pretty clear that the 2005 LRM did not intend for type parameters to be used in this way. The other extension which causes very serious problems is allowing a class to extend a type parameter. I cannot find any LRM text, but the BNF is: class_declaration ::= [ virtual ] class [ lifetime ] class_identifier [ parameter_port_list ] [ extends class_type [ ( list_of_arguments ) ] ]; { class_item } endclass [ : class_identifier] For the base type, it uses the class_type rule, which is: class_type ::= ps_class_identifier [ parameter_value_assignment ] { :: class_identifier [ parameter_value_assignment ] } This class_type rule does not include type_identifier, which is used in data_type and other places to include the name of user defined types and type parameters. I do not see how this can be interpreted to already allow type parameters to be used to specify the base class. To me it is clear that is an extension of the existing LRM and it is one that should be made very carefully. Neither C++ or Java templates allow this. It is clear that this extension creates many issues in the language. If we decide to make this extension we should only do it after very careful consideration of the issues it raises. To me your statement that there are "enough problems with parameterized classes" to justify throwing out backwards compatibility, means that these enhancement have not yet been thoroughly thought out and may not be ready for inclusion in the LRM at this time. > And once we add parameters > without a default, you have the same issue with a class > variable declaration that will now be an error because you > didn't supply an override. This is not true. When a user adds a parameter to a class, he has a choice now whether he want to specify a default value or not. If he does not specify a default value, then all uses of the class will have to be changed to specify a value for that parameter. If he provides a default value, then he should not need to edit any existing usages of the class. That is what users will expect. > Here's another re-use issue that I need a solution to. > > Let's I have a class library prefixed by abc_. Now someone > (most likely in management) decides that the next version of > the class library needs to be prefixed xyx_, but we still > need to support abc_ for backwards compatibility. For any > other type except for a parameterized class, I can do: > > typedef abc_foo xyz_foo; > > But for a parameterized class, the only way I can change its > name is by extending it, which in some cases will require > that the user change an assignment to a dynamic $cast. A > similar problem exists if I need to create a local name for a > parameterized class in an interface or package. Well, I suppose I could say that constantly changing the names of your classes is a management problem and is perhaps better addressed at the management level, but that aside, you can already do this for non-parameterized classes. Since probably most people do not see what the problem actually is, and I only think I know the issue you are talking about, let me give an example and see if this is what the problem is: class abc_foo #(P = 1); endclass typedef abc_foo xyz_foo; abc_foo #(5) x; // legal xyz_foo #(6) y; // most tools probably consider this illegal Most tools will insist you do: typdef abc_foo #(6) xyz_foo_6; xyz_foo_6 z; // legal At least I think this is what Dave is talking about. This is a very unclear area of the LRM. We could extend the LRM to allow the declaration of 'y' to be legal, provided that the parameter overrides are only specified one place. > The need for having nested classes is somewhat alleviated by > having packages, and we're not talking about removed support > for C:: be the default specialization in the declaration of a > variable. So I believe the backwards compatibility issues are > mitigated. > > Dave > > > > > > > -----Original Message----- > > From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] > On > > Behalf Of Mark Hartoog > > Sent: Thursday, October 04, 2007 2:35 PM > > To: Francoise Martinolle; Vreugdenhil, Gordon; Mark Hartoog > > Cc: SV_EC List > > Subject: RE: [sv-ec] "::" is ambiguous in parameterized classes > > > > This is not very consistent with the rest of the Verilog language. > > > > If I have: > > > > class C; > > typdef logic[3:0] T; > > endclass > > > > C c; // class handle to 'C' > > > > C::T x; // variable of type C::T. > > > > Now I change class C to be: > > > > class C #(WIDTH = 4); > > typdef logic[WIDTH-1:0] T; > > endclass > > > > C c; // class handle to 'C' with default parameter value > > > > C::T x; // Now illegal. Must be changed to "C#()::T x;" > > > > If someone has a class that is not parameterized, and > decides to add a > > parameter with an appropriate default value so they do not > break any > > existing usages of the class. With your proposal now they > have to go > > through all the design and change every static reference to class > > objects to C#()::T. > > > > I think this change will discourage good code resuse > practices and be > > viewed as inconsistent with the rest of the verilog language, in > > addition to creating substantial backwards incompatability with > > P1800-2005. > > > > > -----Original Message----- > > > From: Francoise Martinolle [mailto:fm@cadence.com] > > > Sent: Thursday, October 04, 2007 10:29 AM > > > To: Gordon Vreugdenhil; Mark Hartoog > > > Cc: SV_EC List > > > Subject: RE: [sv-ec] "::" is ambiguous in parameterized classes > > > > > > I do agree with Gordon. C:: should only mean a class scope. > > > It was a mistake when we allowed C:: to mean the default > > > specialization as a short cut for typing C#()::. That was > the only > > > reason we did that a year ago. We do not have any advantage in > > > having this mean the default class parameterization, all > it creates > > > is confusion. > > > > > > Francoise > > > ' > > > > > > -----Original Message----- > > > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On > Behalf Of > > > Gordon Vreugdenhil > > > Sent: Thursday, October 04, 2007 1:23 PM > > > To: Mark Hartoog > > > Cc: SV_EC List > > > Subject: Re: [sv-ec] "::" is ambiguous in parameterized classes > > > > > > > > > Mark, > > > > > > Once again you are assuming that your interpretation is > what the LRM > > > definitively states. I disagree. > > > > > > By your argument, $unit:: should also be disallowed since, after > > > all, one can just rename to avoid any name ambiguities. > > > > > > Finally, if a user *does* write the code I did but did so > indirectly > > > due to effects of macro expansion of identifiers, I am > claiming that > > > the meaning is ambiguous and that the most natural > interpretation is > > > the one that I suggest. > > > > > > Gord. > > > > > > > > > > > > Mark Hartoog wrote: > > > > This issue exists because you have named both your type > parameters > > > > 'T'. The sensible solution is to name your type parameters > > > something > > > > different, then you would not have this problem. > > > > > > > > class C #(type T1 = int); > > > > class B #(type T2 = T1); > > > > T1 x; > > > > endclass > > > > endclass > > > > > > > > I'm not sure that naming all your nested type > parameters 'T' is a > > > > coding style that we should be changing the language to > > > make easier to > > > > > > > use. > > > > > > > >> -----Original Message----- > > > >> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On > > > Behalf Of > > > >> Gordon Vreugdenhil > > > >> Sent: Thursday, October 04, 2007 8:35 AM > > > >> To: SV_EC List > > > >> Subject: [sv-ec] "::" is ambiguous in parameterized classes > > > >> > > > >> > > > >> This issue came up at the last EC meeting. > > > >> > > > >> Consider the following: > > > >> class C #(type T = int); > > > >> class B #(type T = C::T); > > > >> C::T x; > > > >> endclass > > > >> endclass > > > >> > > > >> The "::" here has two interpretations -- class scope > > > resolution and > > > >> resolution into a *type*. In this situation there is a > difference > > > >> since the name "C" is overloaded to mean both the name of > > > the class > > > >> and the name of the default specialization. > > > >> > > > >> I think that the user intent here is that "C::T" should > > > mean "T" in > > > >> the enclosing scope and NOT "T within the default > > > specialization of > > > >> C". If the latter interpretation is chosen, then there is > > > no way at > > > >> all to refer to the unspecialized "T" > > > >> from C from within the nested class. If the scope resolution > > > >> interpretation is intended, one can refer to the default > > > >> specialization as "C#()::T". This is particularly > > > important for the > > > >> default in "B" -- it seems clear to me that the expected > > > intent would > > > > > > >> be "I want B to default to the type used to specialize C". > > > >> > > > >> Putting this along side my comments in > > > >> http://www.eda-stds.org/sv-ec/hm/4647.html > > > >> I think there is now a compelling argument to clarify > the LRM by > > > >> stating something like the following: > > > >> When used with a parameterized class prefix, the "::" > > > resolution > > > >> operator shall only be legal within the > parameterized class > > > named > > > >> in the prefix or an out-of-block method > declaration of that > > > >> parameterized class. With a parameterized class > prefix, the > > > "::" > > > >> resolution operator shall only disambiguate names, it > > > shall not > > > >> refer to the default specialization of the class. > > > >> > > > >> I will add the example above when I write up a > proposal for this. > > > >> > > > >> 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. > > > >> > > > >> > > > > > > -- > > > > -------------------------------------------------------------------- > > > 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. > > > > > > > > > > -- > > 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.Received on Fri Oct 5 10:43:53 2007
This archive was generated by hypermail 2.1.8 : Fri Oct 05 2007 - 10:44:26 PDT