Re: [sv-ec] extends construct

Brad Pierce wrote:
>> There are a bunch of issues in terms of exactly what constitutes a
> "class identifier".
>> We've taken the position that "class identifier" is any type identifier
> that denotes
>> a class.
> 
> I agree, but it's important to note here that a type_identifier cannot
> denote a parameterized class.  


Right.

 > A parameterized class can extend a
> specialization of a parameterized class, but I don't think the following
> sentence in 7.23 is accurate --
> 
>    "A parameterized class can extend another parameterized class."

I agree.  If this hasn't been addressed by some other Mantis
item yet, it really should read something like;
     A parameterized class can extend a class type.  Every specialization
     of the parameterized class then extends the given base.  The base
     type can itself be a specialization that uses the parameters of
     the parameterized class when denoting the specialization.

An example or two is likely in order along with this.

> 
> For example, if T were a type parameter, I think it couldn't be legal to
> write
> 
>    class C extends T#(32); ... endclass


Nope.  In fact, there is no way to talk about a parameterized class
as a type -- any reference to it as a type creates a specialization.

Gord.

> 
> -- Brad
>  
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Gordon Vreugdenhil
> Sent: Wednesday, December 20, 2006 12:37 PM
> To: SV_EC List
> Subject: [sv-ec] extends construct
> 
> 
> Sorry for the format of the response here; I'm still not getting
> SV-EC/BC email from the reflector so it is a bit painful to respond to
> any of the posts.
> 
> 
> 
> There are a bunch of issues in terms of exactly what constitutes a
> "class identifier".  We've taken the position that "class identifier" is
> any type identifier that denotes a class.  If that were not the case
> then other situations such as "T::foo();" would not work either if T
> were a type parameter denoting a class.
> 
> I don't necessarily think that all "type expressions" should be
> permitted.  For example, the LRM is very definite that a type reference
> of the form "interface_name.type" may only exist in a typedef.  That is
> a good thing due to parse issues.  "type(va)" doesn't have the parse
> issues so I don't think that there are any technical issues with
> allowing it.  I guess that would also beg the question of whether
> "type(va)::foo();" would be valid.  At this point, I don't see
> compelling reasons to create more work for ourselves in this area; it is
> easy enough to create a typedef for such cases.
> 
> Gord.
> 
> 
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
> 
> ------ original email from Francoise ------- The BNF for the extends of
> a class declaration does not allow type parameters or type references:
> 
> class_type ::= ps_class_identifier [ parameter_value_assignment ]
> 
> { :: class_identifier [ parameter_value_assignment ] }
> 
> 
> 
> I assume that the following class declaration should be legal:
> 
> class B;
> 
> endclass
> 
> B va;
> 
> parameter type T = B;
> 
> class C extends T;
> 
> endclass
> 
> 
> 
> Can we also have a type reference since we can use a type reference as a
> datatype for declaring
> 
> any variable?
> 
> class D extends type(va);
> 
> endclass
> 
> 
> 
> Francoise

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com