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