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

Regarding making all hiding illegal, that would imply that it is also illegal to hide a virtual method. So, that would go back to one of my earlier examples:

interface class IntfA;
  pure virtual void function FuncA();
endclass

class ClassA implements IntfA;
  virtual void function FuncA(); endfunction
endclass

interface class IntfB;
  pure virtual void function FuncB();
endclass

class ClassB extends ClassA implements IntfB;
  virtual function void FuncA(); super.FuncA(); endfunction // Should this be required? It must be allowed.
  virtual function void FuncB(); endfunction
endclass

In the above example, ClassB implements IntfA indirectly in two different ways; 1) it extends ClassA which implements IntfA and 2) it implements IntfB which extends IntfB. If it's an error for an implemented interface class method to hide an inherited method, then it would be impossible to have ClassB since it inherits a method for FuncA(). I might be able to add complicated wording to allow this special case so that it's only illegal to hide non-virtual methods; but it's less special to either treat it as a method name conflict or just allow the inherited virtual method to satisfy the contract inside ClassB.

In real examples, generally the desired behavior is to always declare your methods as virtual in the first place. My concern is that legacy code might not be doing that and there are cases where base classes are sitting in virtually untouchable libraries which are provided by 3rd parties.

-Brandon

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com]
Sent: Monday, June 27, 2011 4:29 PM
To: Tipp, Brandon P
Cc: SV_EC List
Subject: Re: [sv-ec] Ongoing overrides/implements refinement

I'm fine with allowing the hiding, but as I said initially, I've never seen
any real SV TB code do that intentionally. Do you really believe
that is "desirable"? If so, fine.

Given wanting to hide it, I definitely like treating this as a conflict
that requires explicit definition.

BTW, I think that "virtual" should be required whether there is a
hiding definition or not -- people already get confused by the "implicit"
virtual qualification and getting that implicitly from the interface
class is not desirable as far as I am concerned. The rule is then
even more clear -- the first "satisfying definition" must be a
virtual method or prototype that matches the implemented prototype.

Gord.

On 6/27/2011 4:06 PM, Tipp, Brandon P wrote:
> 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.
>
>

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