RE: [sv-ec] Abstract classes and virtual methods

Dave,

 

There are a few things that the new proposal doesn't address that we may
as well fix now that we are discussing it.

 

1)       A class that contains any undefined method must be explicitly
defined abstract (virtual class), or it shall be an error.

2)       A concrete class --- one with all of its methods defined ---
may also be defined as abstract. This is an explicit request from the
author of the class to disallow creating objects of that particular
type.

a.       A corollary to this rule is that any class (base or derived)
may be made abstract.

3)       It perfectly legal for a derived abstract class to override a
virtual method with an undefined method, even when the base method in
the base class is defined.

 

I think the verbiage in Dave's proposal that discusses direct
construction is unclear. The only way objects are created is by
explicitly calling the new method. There is no direct/indirect object
creation. When the system arranges for the base object's new method to
be called on behalf of a derived class, it acts as an initializer, not a
creator.

 

Also, Dave proposes that we use the "extern task/function" syntax to
signal an undefined method. Hence, a method declared as extern, with no
body defined anywhere using an out-of-body declaration (Class::method)
is deemed undefined. This is definitely an improvement since it
eliminates the existing ambiguity. However, it does require the compiler
to ensure that an out-of-body declaration does not exist, which creates
separate compilation issues specially with regards to rule (1) above.
Perhaps, we should consider a more succinct syntax that does not require
global analysis to denote undefined methods. For example, we could
borrow from C++'s pure abstract method syntax:

 

    virtual class foo;

            virtual task F() = void;

    endclass

 

This allows the compiler to determine that method foo::F() is pure
virtual at the moment that foo's declaration is processed, and not until
after everything has been compiled.

 

            Arturo

 

________________________________

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Rich, Dave
Sent: Friday, January 20, 2006 4:38 PM
To: Mehdi Mohtashemi; sv-ec@eda.org
Subject: RE: [sv-ec] Abstract classes and virtual methods

 

Hi Mehdi,

 

This is now mantis 1308
http://www.eda.org/svdb/bug_view_page.php?bug_id=0001308

 

Can you put that on the agenda? Is he next meeting on the 23rd?

 

________________________________

From: Mehdi Mohtashemi [mailto:Mehdi.Mohtashemi@synopsys.com] 
Sent: Friday, January 20, 2006 2:45 PM
To: Rich, Dave; sv-ec@eda.org
Subject: RE: [sv-ec] Abstract classes and virtual methods

 

Dave, 

I agree that we should do more clarification, perhaps this can be taken

up quickly and looked at. 
Just a note on virtual (abstract) classes. I believe you can 'define' an
abstract

class, and only allowed to extend it, once extended, you can then
'declare' 

classes of that type, which then allows you to 'construct' it (with
new).

- Mehdi

 

________________________________

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Rich, Dave
Sent: Friday, January 20, 2006 2:27 PM
To: sv-ec@eda.org
Subject: [sv-ec] Abstract classes and virtual methods

There are a number of problems in section 7.19 that need to be
addressed, Ideally, I would have liked to address each issue separately,
but the text is so intertwined that it was too difficult to come up with
separate proposals. I'll list the separate proposals that this single
proposal addresses.

 

1.	Abstract classes and virtual methods are two separate features
and need to be defined independently. It would be best to split virtual
methods from abstract classes and describe them in their own section.
They were only bundled in one section because they use the same keyword
"virtual", but that is not a good reason. Prototype virtual methods
belong with abstract classes. This is a clarification. 
2.	We need to distinguish between the instantiation of a class
object and its handle. You declare class handles and construct class
objects. It should be legal to declare abstract class handles, but not
construct abstract class objects (i.e. call the new operator). I think
this was the actual intent, and this is just a clarification 
3.	We need to clarify what a matching prototype for virtual method
is. This is an erratum. I am proposing that types must match, but formal
identifiers and defaults do not need to match. 
4.	What exactly is a virtual method without an implementation?. The
example shows a function without a statement body, but that function has
an implementation and is callable by Verilog standards. If I look at
Vera, it uses the same syntax as a prototype for an out-of-class-body
prototype to denote a virtual method without an implementation, so I am
suggesting we use the same extern syntax as we do in SystemVerilog. This
is a major hole in the LRM and will require a BNF change. 
5.	The old text is written in an informative style in a normative
section. Because of that, the rules about the interaction between
abstract classes and prototype virtual methods are not clear at all.
I've tried to clean that up where I could. 

 

I've attached two versions of the proposal; one with markups, and one
without for easier reading.

 

Thanks,

 

Dave

 

 

David Rich
Verification Technologist
Design Verification & Test Division
Mentor Graphics Corporation
dave_rich@mentor.com
Office:   408 487-7206
Cell:     510 589-2625