As requested in the SV-EC meeting, here is a summary of the issues that raised discussion points from my list of review comments that I had mailed out. Items that I skip here are either editorial or obviously required fixes (such as the grammar). --------------- 5) The proposed re-wording for 8.15 ($cast) isn't quite right. It wouldn't allow a cast from an interface class type expression to a class type target (since the interface class could not possibly be a superclass of the class). I think that we could change the rewording of the second bullet to just: o the type of the source expression is an interface class --------------- Notes: the main point here is that one cannot in general have strong statements regarding compatibility of handles referenced by interface classes. So in general if you have an object that "implements" interface class C, it may or may not implement D. Since that is not necessarily a relationship about C and D (they may be unrelated), one must allow any $cast with an interface class source at compile/elab and do the check at run-time. While there are some checks that could be done at compile/elab (i.e. if the entire design has no class that implements both C and D one could report an error), such cases would be difficult to fully express in the LRM and would still leave some checks as dynamic. As a result, it is simpler to just allow the general case in the static requirement and leave the rest for simulation time. --------------- 9) It is legal to access parameters in an interface class as "IntfClass::param_name". Is it legal to have: IntfClass ic = some_object; int x = ic.param_name; In other words, are static data members (such as parameters) accessible as a select from a variable of an interface class type? --------------- Notes: While it is likely that there are no substantive issues in allowing dotted parameter name references, it was the committee consensus that we are likely better off to make such references illegal for now in order to reduce potential confusion for users. The "::" qualified reference makes it more clear that this parameter is related to the *type* of the reference, not to the object. Since interface class variables cannot have other non-method dotted refereces (since there are no other data members), it seems more reasonable for the time-being to keep interface class parameter references closely couple to the type and require a "::" reference. --------------- 14) 8.25.5.1 In the first example, I think I disagree with the requirement to have funcBase be defined in ClassExt. Doesn't that requirement conflict with the example in 8.25.2? I do agree with the second example and the examples in 8.25.5.2 and 8.25.5.3. --------------- Notes: Gord -- I think this was a hold-over from an earlier review. You can ignore this one. --------------- 16) Can a handle to an abstract base class be used as a reference to an implemented method even if the method is not directly declared? So is the following legal: interface class intf; pure virtual function void f(); endclass virtual class base implements intf; endclass //... base b = some_valid_object_derived_from_base; b.f(); // <<<< is this legal? It is not clear from the proposal that this is legal although my expectation from committee discusion is that people would like it to be. We should carefully consider that choice. Allowing "base" to essentially inherit the pure function prototype weakens the distinction between "extends" and "implements" and also may pose later surprises if "base" doesn't implement everything. By requiring "base" to have all needed prototypes, one gets a clear picture at the point of the implements of what obligations may still be outstanding in the type hierarchy derived from base. So I'd prefer to require "base" to prototype all implemented methods or, at least, to disallow calls from "base" to an unprototyped implemented method. --------------- Notes: See my response to Tom in: http://www.eda.org/sv-ec/hm/8004.html for additional commentary. The consensus of the committee was that an abstract class shall have compatible definitions for all implemented interfaces visible at the point of the "implements" being expressed. The satisfying prototype could be visible via class inheritance. For example, the following is legal: interface class intf; pure virtual function void f(); endclass virtual class base; pure virtual function void f(); endclass virtual class ext extends base implements intf; endclass "ext" inherits a compatible (pure) virtual method from "base" which satisfies the require for "f" from "intf". The original example that I raised would not be legal as no satisfying definition is visible. --------------- 17) Does the user need to explicitly indicate "virtual" on the first implementing definition or is that implied by the implements in the same way as it would be during inheritance? interface class intf; pure virtual function void f(); endclass class base implements intf; function void f(); endfunction endclass --------------- Notes: Consensus was that "virtual" is not applied by way of an implements. Since "f" is not defined to be virtual this example would be an error. The following would be legal: interface class intf; pure virtual function void f(); endclass virtual class base; pure virtual function void f(); endclass class ext extends base implements intf; function void f(); endfunction endclass This is legal since method "f" is determined to be virtual through the normal "extends" aspeect of the class inheritance -- since "f" is virtual in "base", the definition in the overriding class "ext" continues to be virtual. Thus "ext" satisfies the requirement from "intf" to provide a compatible virtual method "f". --------------- 18) The question of whether a pure virtual hides a non-virtual is still open. So is the following legal: class base; function void f(); endfunction endclass interface class intf; pure virtual function void f(); endclass virtual class der extends base implements intf; endclass class der2 extends der; function void f(); endfuntion endclass If you have: der d = some_legal_obj; d.f(); what is called? --------------- Notes: based on the consensus for 16 and 17, this is not a feasible scenario. The design as given would be illegal since "der" does not have a visible virtual method "f" to satisfy the requirement from "intf". The user would either have to declare base::f as virtual or would have to define a (pure) virtual prototype in "der". In the latter case, such a definition would hide the non-virtual method from base as defined by existing class extension rules. --------------- 19) Can one call randomize() via an interface class handle? Certainly on cannot use inline constraints, rand_mode or constraint_mode (which should be noted in the LRM). --------------- Notes: The consensus was the randomize should be legal. The conceptual view is that all classes (by LRM definition) provide a virtual randomize method. So by considering any interface class to implicitly have a requirement for such a method, all classes can satisfy that requirement (by definition). We did not want to get into that kind of rationale in the text however; we believe that it is sufficient to note that randomize is legal. There should be commentary that while inline constraints, rand_mode and constraint_mode are "legal", by definition of how name resolution is done, they can't address any data members via an interface class reference since interface classes have no data members. --------------- 20) What does $bits return for an interface class handle? How does this relate to streaming operators? Can one stream from/into an interface class handle? 11.4.14.1 needs to define streaming behavior for interface class handles. --------------- Notes: The current status of $bits and streaming for classes is pretty bad already. There was at least weak consensus that we should make these illegal in this PAR for references through interface class variables. Trying to define something rational here is likely to require substantial work in the core existing definitions. We were out of time on this one so if anyone disagrees with my understanding of the agreement, please say so.