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.