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

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.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.