Re: [sv-ec] classes questions

Oh, one important detail here.

Given:
    class C #(int p = 1);
       extern task t();
    endclass

    task C::t();
    endtask

It is important to distinguish that such a reference
is NOT a reference to the default specialization but
is actually part of the unspecialized parameterized class.

Gord.

Gordon Vreugdenhil wrote:

> 
> Brad Pierce wrote:
> 
>> Gord,
>>
>>
>>> The grammar actually requires a "class_identifier" as the prefix of
>>
>>
>> "::".
>>
>> Where does the grammar do this?  The BNF doesn't. Do you mean the
>> unboxed text in the first paragraph of 7.21?  
> 
> 
> Yes.  I didn't check that with the full grammar which does allow
> the more general form.  So C#(1)::x is allowed.  Given that,
> treating C::x as a reference into the default specialization
> is quite reasonable.
> 
> 
>>
>> The BNF does not even support the example on the next page
>>
>>     Base::print( Base::hex, 66 );
> 
> 
> 
> Hmm - apparently this was overlooked wasn't it.  method_call
> covers all the non-static cases, but not the static cases.
> It looks like ps_or_hierarchical_tf_identifier should just have
> a class_scope variant added to it.
> 
> 
>> For consistency with the rest of the BNF, I'd expect that a static
>> method or class property could be prefixed with any class_scope.
> 
> 
> Static class properties are covered I think.  A primary is
> permitted to have a class_scope before the "hierarchical_identifier"
> portion of the name.  Blocking assignments are also covered.
> 
> Gord
> 
>> Following is the BNF for class_scope --
>>
>>    class_scope ::= class_type ::
>>
>>    class_type ::=  ps_class_identifier [ parameter_value_assignment ]
>>                       { :: class_identifier [ parameter_value_assignment
>> ] }
> 
> 
> 
> 
>> -- Brad
>>
>> -----Original Message-----
>> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
>> Gordon Vreugdenhil
>> Sent: Tuesday, October 17, 2006 9:20 PM
>> To: Arturo Salz
>> Cc: Francoise Martinolle; sv-ec@eda.org
>> Subject: Re: [sv-ec] classes questions
>>
>> Arturo,
>>
>> I am somewhat Ok with allowing things like C::x, but in our experience,
>> users have had more difficulty in distinguishing that C::x does NOT mean
>> "the only x in the type C" but rather that it means "the x in the type
>> created by a default specialization of C".  This tends to be less an
>> issue when using C explicitly in a type construction context.
>>
>> The grammar actually requires a "class_identifier" as the prefix of
>> "::".  I think there is a distinction in that allowing "C::x" confuses
>> the idea of "class type" and "parameterized class as a type
>> constructor".
>>
>> Our basic approach so far has been to allow a default specialization
>> only in a context in which an explicit specialization would be
>> permitted.  Since the current BNF doesn't allow C#(1)::x, we don't allow
>> C::x.  Since the BNF does allow any of:
>>     typedef C#(1) C_1_type;
>>     C#(1) some_obj;
>>     class D extends C#(1); .... endclass; (and a few others), we allow
>> default specialization in those contexts.
>>
>> This was an LRM interpretation judgement call; I would certainly be in
>> favor of a clarification here.
>>
>> If we would allow explicit specialization in any of the other contexts,
>> I'd be more amenable to allowing implicit specialization as well even
>> though I think that allowing it can be quite confusing.
>>
>> Gord.
>>
>>
>> Arturo Salz wrote:
>>
>>
>>> Gord,
>>>
>>> I agree with most of what you wrote. But, I disagree with your last
>>> statement:
>>>
>>> Given the declaration:
>>>
>>>    class C #(int p = 1);
>>>       static int x = p;
>>>    endclass
>>>
>>> Then C::x does indeed mean "the x in the type created by the default 
>>> specialization". Otherwise, what's the point of providing a default 
>>> parameter?
>>> Why would you allow     typedef C xyz;    // this does mean the 
>>> default specialization
>>> But not allow C::x ? BTW, what about the form "C()::x"? That is very 
>>> clear that it means the default specialization.
>>>
>>> Another question regarding this is:
>>>
>>>    class D #(int p = 1);
>>>       enum Bool { FALSE, TRUE = p };
>>>    endclass
>>>
>>> Would you disallow "D::Bool" , but allow "typedef X D::Bool" ?
>>>
>>> I would agree with your assessment if Brad's proposal to omit default 
>>> types passes and the parameterized class were written with no default.
>>>
>>>     Arturo
>>>
>>
>> -- 
>> --------------------------------------------------------------------
>> Gordon Vreugdenhil                                503-685-0808
>> Model Technology (Mentor Graphics)                gordonv@model.com
>>
>>
> 

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