RE: [sv-ec] "::" is ambiguous in parameterized classes

Mark,

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. 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.

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.

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.