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