RE: [sv-ec] Ongoing overrides/implements refinement

One of the tweaks that I made in my last revision is that a "virtual method override can be provided by an inherited _virtual_ method definition" where the proposal previously just stated "inherited method definition". I probably should have explicitly added that an inherited non-virtual method cannot fulfill a contract. So, I agree with your rule #1.

Regarding rule #2, I wouldn't want to make it illegal to hide an inherited method since that could make some desirable structures illegal without providing any hope of a work-around. I'd rather treat that as a "method name conflict" scenario, where the class which is both inheriting a non-virtual method and implementing the interface class is required to define a new method to override both. I think that clarifies the ambiguity in the code without being overly restrictive. E.g., given your example, you'd need the following:

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

      class base;
           function void f(); endfunction
      endclass

      class derived extends base implements intf;
           virtual function void f(); super.f(); endfunction
      endclass

Providing a definition of derived::f() is only required because base::f() is non-virtual. I'm not sure if declaring derived::f() to be virtual should be required, but it would at least implicitly be virtual at that point.

-Brandon

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Gordon Vreugdenhil
Sent: Monday, June 27, 2011 2:16 PM
To: SV_EC List
Subject: [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.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.