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

Tom,

I owe a summary of committee discussion on my list to the
reflector; I'll do that either late tonight or tomorrow but let
me respond to 16-18 right away.

I don't agree with your suggestions on 16; I definitely do not
want to open the door in any way to extending interfaces into
a class. That both defeats the orthogonality of the intent of
"extends" (i.e. a class could not then extend a concrete base
and implement an interface) and would re-introduce very
problematic questions about visibility through inheritance.

There was agreement in discussion that my example in
16 as written should not be legal. A virtual class must
define a prototype (or inherit one from another class)
for each implemented class method. That makes the
contract point clear and provides a clear (forward) obligation
to any non-virtual class extending the virtual class.

I don't think that we'd want to disallow virtual (abstract)
classes which implement interfaces. An abstract class
should be allowed to be partial in the sense of not defining
implementations but must be complete in terms of
defining prototypes that satisfy the contract obligations
(whether directly or through inheritance).

In 18, the base method is NOT virtual and as you point
out in your comments on 17, we would not want it to become
implicitly virtual by way of "der" implementing the interface
class. But the committee's discussion of 16 would require
"der" to provide a prototype (which would hide the non-virtual
base method) or would generate an error since the base method
is non-virtual. That is clean and doesn't require any particular
change or special consideration of the normal class rules.

All of the above is related to a very strong paradigm requirement
that I would like to see met. I would like to be able to say that
adding an "implements" to any class never changes the behavior
of that class in any way; it "obligates" the class the behave in
some manner, but it doesn't impact the behavior of the class.
So, assuming that the code compiles/elaborates, one can
generalize any class based design by adding "implements"
clauses broadly (with wild abandon) and not change any of
the existing class behavior. Keeping that as a strong requirement
will, I believe, lead to much more compositional code in the
long term with much more consistent ways of reasoning about
interactions.

Gord.

On 8/1/2011 4:02 PM, Alsop, Thomas R wrote:
>
> 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
>
> **
>

-- 
--------------------------------------------------------------------
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.