[sv-ec] Ongoing overrides/implements refinement

In thinking through all of the inheritance relationships versus
"implements" relationships, here is another case that might be
useful to clarify/restrict. This is related to the recent discussion
of the relationship between interface methods and inherited
method implementations.

In a normal class, a "virtual" method can hide a non-virtual.
So, I can have:
      class base;
            function void f(); endfunction
      endclass

      class derived extends base;
            virtual function void f(int a); endfunction
      endclass

but I can't have:

      class base;
            virtual function void f(); endfunction
      endclass

      class derived extends base;
            function void f(int a); endfunction
      endclass

The difference is that "virtual" is persistent through
*later* extensions but it doesn't go the other way.
So in the first situation, "f" has no obligation to be
override compatible since it hides base::f, it doesn't
override it. In the second case, derived::f doesn't hide
base::f, it is a virtual override (even though it doesn't
say virtual in "derived") and is thus an error.

So why is this relevant to interface class methods?

Well, the question I have is what we want to do about
the following:

      interface class intf;
           pure virtual function void f();
      endclass

      class base;
           function void f(); endfunction
      endclass

      class derived extends base implements intf;
      endclass

Is this legal? In other words, can a non-virtual base method
satisfy an "implements" requirement?

I think that my preference is to say that a base method must
be virtual in order to provide a satisfying implementation (i.e.
"virtual" is effectively part of the prototype that must match).

So, assuming that is illegal, what about:
      virtual class derived extends base implements intf;
      endclass

Now since I've made derived into a virtual class, we could
decide that "intf" simply provides a hiding virtual definition
and that it simply becomes an obligation for a future class
to implement a compatible "f".

I would be Ok with that interpretation (which should be made
explicit) but I'm wondering whether it wouldn't actually be
more helpful to make this situation an error. In general, I've
seen very few situations in real SV code where a user *intended*
to have a virtual method hide a non-virtual inherited method;
that tends to be a bug versus the user intent. That is likely
to be exacerbated with interface classes, so I think that my
preference would be to say that such behavior is an error
rather than a hiding definition.

So my suggested rules would be:
    1) a non-virtual method shall not satisfy the obligation to
         implement and interface class method prototype
    2) it shall be an error for a interface class method to hide
         a method in an implementing class's base type.

As I said, (2) is not necessary, and is in fact more restrictive
than the rules for normal inheritance, but based on experience,
it seems to be a good restriction.

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.