Re: [sv-ec] Follow-up from last call -- legality of virtual/pure virtual overrides

I believe that the consensus at the meeting was that it should be legal
to have a base class provide the implementation via inheritance.

So the following should be legal:

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

class classA;
   virtual function void f(); $display("hello"); endfunction
endclass

class classB extends classA implements intfA;
endclass

Note that in the above "classA" does not explicitly implement
"intfA" so you could not cast from a classA object to an intfA
reference even though the classA method is the one that is
in fact used to satisfy the implements requirement in classB.

Gord.

On 6/27/2011 9:24 AM, Tipp, Brandon P wrote:
> I've already made changes to the proposal (not yet uploaded) to remove the "inherits method prototypes" wording. I had thought that it would make things simpler to understand, but instead it implied other, more complicated cases. If we decide that it is illegal to declare a pure virtual method to override a virtual method definition, then it would be inconsistent (and confusing) to allow an inherited method to provide the override for a pure virtual method in an implemented interface class.
>
> The key question for me right now is regarding the interface class proposal. Do we want an inherited method definition to be able to satisfy the "contract" to provide a definition for a pure virtual method in an implemented interface class?
>
> -Brandon
>
>
> -----Original Message-----
> From: Vreugdenhil, Gordon [mailto:gordon_vreugdenhil@mentor.com]
> Sent: Friday, June 24, 2011 5:12 PM
> To: Tipp, Brandon P; neil.korpusik@oracle.com
> Cc: SV_EC List
> Subject: RE: [sv-ec] Follow-up from last call -- legality of virtual/pure virtual overrides
>
> Brandon,
>
> My basic point in the call was that we probably can't
> use the word "inherited" at all when talking about the
> relationship between the interface class methods
> and the implementing class. We'll likely have to
> use some phrase such as "must implement a
> method or define a pure virtual prototype which
> is prototype compatible with the interface class".
> We'd then need to do a tiny bit of work to generalize
> other terminology so that "prototype compatible" is
> actually well defined. My intent in use is the
> generally list of requirements given in the LRM --
> formals of the same name, compatible types, etc.
>
> Gord.
>
> ________________________________________
> From: Tipp, Brandon P [brandon.p.tipp@intel.com]
> Sent: Friday, June 24, 2011 4:45 PM
> To: Vreugdenhil, Gordon; neil.korpusik@oracle.com
> Cc: SV_EC List; Tipp, Brandon P
> Subject: RE: [sv-ec] Follow-up from last call -- legality of virtual/pure virtual overrides
>
> Applying this to interface classes, consider the following:
>
> interface class intfA;
> pure virtual function void f();
> endclass
>
> class classA implements intfA;
> virtual function void f(); $display("hello"); endfunction
> endclass
>
> interface class intfB extends intfA;
> pure virtual function void g();
> endclass
>
> class classB implements intfB;
> virtual function void g(); $display("world"); endfunction
> endclass
>
> If you look at this as being equivalent to Gord's situation, then by the discussion below the code above should be illegal. Can you work around the error by allowing classB to declare f() to override both the inherited f() and the pure virtual method prototype from intfA?
>
> -Brandon
>
>
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Gordon Vreugdenhil
> Sent: Friday, June 24, 2011 4:13 PM
> To: neil.korpusik@oracle.com
> Cc: SV_EC List
> Subject: Re: [sv-ec] Follow-up from last call -- legality of virtual/pure virtual overrides
>
> Neil,
>
> My (academic) argument for why one could omit "virtual" on
> "d" is that the method in "d" isn't actually pure if you assume
> that the implementation can be inherited.
>
> Personally, I'm fine with your (assumed) rules. Briefly,
> it boils down to the following clarification:
> It is not legal to define a pure virtual prototype for
> an inherited method unless the inherited method
> is itself pure virtual.
>
> A related clarification might be:
> It is not legal to declare a pure virtual prototype for a
> method in the same class in which the method is
> defined.
>
> Given the above, "d" is clearly illegal since the method
> definition from "c" can't be inherited. That means that
> there is no possible rationale for claiming that "f" is
> implemented in "d" and there is then no need to
> explicit say that the *syntax* "pure virtual"
> requires the class to be virtual -- that is not needed
> since the syntax and semantics would be aligned.
>
> So, I'd prefer to go with the above clarification(s) and would
> be willing to open a Mantis with a proposal on that if
> there are no objections.
>
> Btw, you might recall that the origination of the entire issue
> was related to using "inheritance" to describe the
> relationship between an interface class method and the
> implementing class -- the above clarification would make
> it quite important to correct that wording.
>
> Gord.
>
>
> On 6/24/2011 3:55 PM, Neil Korpusik wrote:
>> It is my understanding that pure virtual methods are only allowed within
>> an abstract base class. That would make class d in your example illegal.
>> function f in class d can't be declared pure.
>>
>> If we change the example to be the following, I would still say it is
>> illegal. In this version, abstract base class d is changing function f
>> from
>> a virtual to a pure virtual function. Since the definition of pure
>> virtual
>> is that there is no implementation, I don't see how this could be legal.
>> It would be very confusing to say that the new definition of f in d
>> overrides what is in c to now not have an implementation.
>>
>> module top;
>> virtual class c;
>> virtual function void f(int a); endfunction
>> endclass
>> virtual class d extends c;
>> pure virtual function void f(int a);
>> endclass
>> endmodule
>>
>>
>>
>> Neil
>>
>>
>>
>> On 06/24/11 09:10, Gordon Vreugdenhil wrote:
>>> This is just to follow-up the questions that I raised in the last EC
>>> call.
>>>
>>> Is the following legal:
>>>
>>> module top;
>>> virtual class c;
>>> virtual function void f(int a); endfunction
>>> endclass
>>> class d extends c;
>>> pure virtual function void f(int a);
>>> endclass
>>> endmodule
>>>
>>> There are a couple of questions about the legality:
>>> 1) can "c" provide an implementation for a later
>>> "pure virtual" prototype?
>>> 2) if (1) is permitted, can "d" be non-virtual?
>>> 3) if (1) is not permitted, can the "f" in some
>>> further extension of "d" call "super.f"?
>>>
>>> If the "f" in "d" is supposed to "hide" the virtual
>>> definition in "c" (which I find very troublesome),
>>> is the prototype permitted to change? i.e. can you
>>> then have:
>>> pure virtual function void f(reg a);
>>> as the prototype in "d" -- "hiding" generally means
>>> the incompatibility is Ok.
>>>
>>> None of these situations are clearly addressed by
>>> the current rules and definitely impact how we talk
>>> about various interface class / class interactions.
>>>
>>> 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.