[sv-ec] Last major issues on interface classes - 1356 review

Gord, I'm only responding to questions 16-18 for now. All the others, I'll get to tomorrow as they are less critical. Let's bottom out on this first and then tackle the minor issues left.

-Tom

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.
talsop> I agree that we should require the base to fulfill the implements contract and prototype the methods. This is the meaning behind 'implements'. I think the act of inheriting methods from the parents should come from the 'extends' construct. This keeps the rules crystal clear on usage of the two constructs. That said, for abstract classes, I can see people wanting to 'inherit' interface class methods or in other words, inherit the contract so that the abstract class carries with it now the contract thereby requiring child classes to prototype the method. If we really want this why don't we just allow an abstract class to 'extend' an interface class or multiple interface classes? Then the above implementation becomes:

        interface class intf;
            pure virtual function void f();
        endclass
        virtual class base extends intf;
        endclass
           //...
        base b = some_valid_object_derived_from_base;
        b.f(); // <<<< This would then be legal

This makes a clear distinction between the abilities that we give the 'implements' vs 'extends'. We can state in the LRM that abstract/virtual classes may either 'extend' an interface class (in which case they inherit the contract for child extensions) or 'implement' them which would force the abstract class to provide the prototypes. This clarifies where in the parent/child hierarchy who is inheriting vs who is really implementing. Currently the proposal does not allow abstract classes to extend an interface class, but we can change this.

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

talsop> It's a contract. When you implement an interface class the return type, the number of arguments, and types must all match. If the interface class declares a method as virtual, then the implementing class must declare it as virtual. We should make a 'shall' statement on this and note that implementations will issue and error if the user forgets this. So my take on this is the user must explicitly do this and we do not have any inheriting notions here. Can you imagine if the implementing class did not make this virtual, but it was 'inherited' how hard this would be to debug when the end user thought he was implementing an non-virtual interface method and it turned out to be polymorphic?

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?

talsop> Going back to my answer on Q16, this become clear. The 'der' class above, even though it's abstract, would still be required to prototype the intf class, however, since the prototype was additionally extended from base, the prototype requirement is met. So while it is declared as a virtual class, in this case it would be fully prototyped. The only reason to declare 'der' as virtual would be to include other pure functions.

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Gordon Vreugdenhil
Sent: Monday, August 01, 2011 8:55 AM
To: SV_EC List
Subject: [sv-ec] Additional 1356 review (interface classes)

Since I haven't seen any other review of 1356 since the ver7 upload, I went ahead and did another fairly deep review. Attached are my review comments.

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.