Re: [sv-ec] classes questions

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?  

The BNF does not even support the example on the next page

    Base::print( Base::hex, 66 );

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.

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