Re: [sv-ec] question about name resolution in classes

francoise martinolle wrote:
> Gordon,
> Let me use the term "lexically static" rather than "locally static"
> for this.  Then I think that a resonable approximation would be
> that:
>       A lexically static type is any type *except* the following:
>          1) a type denoted by a type parameter
>          2) a type denoted by a typedef whose type is
>             defined by the "interface_instance_identifier . type_identifier"
>             rule
>          3) a type defined by a parameterized class specialization
>          4) a typedef of a type that is not lexically static
>          5) a class derived from a type that is not lexically static
> 
> I think that covers all of what I consider to be the "elaboration time
> types" and is perhaps close to what you had in mind with the "locally
> static" suggestion.
> 
> 
>>>I like the above definition except for the terminology of lexically
>>>static type. 
> 
>>>It seems that you chose lexical to mean that the type name space is
>>> entirely known at parse time.

Right.


>>>But I do no have a better idea at the moment.

I couldn't come up with anything better at the time either;  if
anyone has terminology suggestions here, that would be welcome.

It might be more clear to go towards the term "elaboration type"
but that is somewhat misleading as well.


>>>The list you propose seems complete, I have reservations that any type 
>>> defined by a parameterized class specialization
>>>is not lexically static. I think it depends on how the parameters are
>>> used inside the class.
> 
>>>Just like in your example above the parameter passed as specialization
> 
> value of a class may just be used in sizing
> 
>>>a type inside the class:
>>>    class vector #(int size = 1);
>>>        bit [size-1:0] a;
>>>    endclass


Certainly.

Including paramterized classes is primary just me being pretty
conservative about where the language might go.  I don't think
there is any reason to include parameterized class in the list
right now, but there are several directions in which I could see the
language going where we might need to treat them as not lexically
static.  For  example, if at some point we'd want to provide different
implementations for particular specializations (as one can
do in C++), it might be difficult to deal with the change if
we require resolution.  The same would be true if one wanted
to have some form of conditional declarations inside a
parameterized class ("only override and define these properties
if the type parameter is real").  None of this is legal right now,
but it is certainly possible/likely that people would make
proposals along such fronts.

Having a parameterized class be lexically static under some
conditions and not others might be confusing and be too
sensitive to design change.

If we don't include parameterized classes in the list I proposed,
we might be making things more difficult in the future.  I think
that I'd rather see the community gain a bit more experience
about complex designs prior to committing to a direction.
Excluding parameterized classes from being lexically static
for now gives us more space to consider issues and is easy
to relax later.

I don't feel too strongly about this so if others are opposed
to being conservative on this, I wouldn't argue too much.

Gord.

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