[sv-bc] Resolution of inherited type names

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Fri Sep 07 2007 - 15:11:55 PDT
Mark, I think I raised this once a long time ago but I'll raise
it again since I think we've both neglected to discuss this scenario.

Given your rules, I don't think you can have symmetric handling
of type names versus member/property names when inheriting from
an opaque type.  Specifically, what rules would you apply
when dealing with something like the following:
    module child #(type T = int);
      int T2;
      class C extends T;
         T2 x;
      endclass
    endmodule

In order to be consistent with your approach elsewhere, would
you have to assume that "T2" is an inherited type and defer
all of the handling until elaboration?  Is that even possible
to parse in general if you don't know whether T2 denotes a
type or a variable?

I suspect that for inherited types in such a situation
you would have to adopt an approach similar to mine, would
you not?

My suggested approach to solving such a scenario is
similar to what I want to do in every case; require explicit
referencing.  Here, I'd either be willing to allow something
like "typedef T::T2 T2;"  or "typedef super.T2 T2" to
directly declare that "T2" is an inherited type.  In the
long term, as I've suggested before, I'd like a more complete
"specification" for "T" that would directly give the assumptions
about what T provides rather than working from indirect
information in the body of C.

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Sep 7 15:33:21 2007

This archive was generated by hypermail 2.1.8 : Fri Sep 07 2007 - 15:33:49 PDT