Re: [sv-ec] classes questions

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