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

>From: "Rich, Dave" <Dave_Rich@mentor.com>

>1. What level of matching defaults is needed for virtual methods? The
>current proposal only requires the presence of a default to match for
>each argument, not their expressions. I think a matching expression is
>unnecessary and not very useful.

I agree that trying to check for matching expressions is a pain.  Gord
suggested the proper solution for this, which is to have the default
value inherited from the original virtual method declaration.  This
takes care of ensuring that all of the virtual method implementations
have a default, without requiring the user to explicitly declare it on
each of them.

From a design philosophy viewpoint, default argument values appear to
me to be a convenience feature for the caller.  They are part of the
interface to the method, which is the same for all implementations.
They don't appear to me to be part of the encapsulated internals of
the method, which must be allowed to be different to support polymorphism.


>2. The syntax for declaring a method without an implementation. The
>current proposal reuses the syntax for out-of-class body, which is what
>Vera does. Some have suggested that this might be visually ambiguous,
>but I think since you have to mark the class as 'virtual', it is
>unlikely that you will be providing out-of-class bodies at the same
>time.

Is this only visually ambiguous, or actually ambiguous?

As I understand the problem, it was impossible to distinguish between
a virtual prototype and a virtual implementation that was empty.  Does
the new suggested syntax also leave an ambiguity?  Isn't it possible
to have a virtual implementation that has an out-of-class body, and
wouldn't this suggested syntax for a virtual prototype be
indistinguishable from it?  Or is there some way to distinguish?


Steven Sharp
sharp@cadence.com