Re: [sv-ec] disable class method

>From: Gordon Vreugdenhil <gordonv@model.com>

>I agree that disabling a method disables all invocations.
>
>I am less certain about why disabling a virtual should be
>illegal.  If one has a base class with two derivations
>and wants to disable all of behavior of one "branch",
>it seems to me that would be reasonable.  Is there a
>particular reason why virtual should be a special
>exception?

As I said in my response to Daniel, I don't think it is actually
legal to apply a disable to a reference through a class object,
since that is not a hierarchical path name.

I also think that if a disable is allowed inside another method
of the class, it would not be an implicit reference through the
'this' handle.  It is a static hierarchical path name, since that
is what disable accepts (and if you cannot apply a disable to an
explicit reference through a class object, I don't see why you
would be able to apply it to an implicit reference through 'this').

That leaves us with no way to disable through a class object, and
therefore no way to select an implementation of a virtual method.
All disables would be of a static reference to a particular
implementation.

Note that if a disable is allowed inside another method of the
class, and it is not considered to be an implicit reference through
the 'this' handle, this makes the reference appear inconsistent
with the same name used in a call.  This could be confusing.  That
would be a reason to disallow disables on virtual methods.

Before going to any effort to try to define these things, I would
want to see a realistic use for them.  Since it is difficult to
find such a use for disabling re-entrant tasks outside classes, I
have trouble believing there is a use inside them.  With virtual
methods, the usefulness becomes even less clear.

Somebody may eventually come up with a reasonable use for these
things.  Until then, we are probably best off to disallow anything
that is unclear.  If nothing else, it will avoid defining it in a
way that prevents that future reasonable usage.

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.