Re: [sv-ec] disable class method

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?

Gord.


Arturo Salz wrote:
> I agree with Steve:
> 
> - Disabling a method ought to disable all invocations of the task.
> 
> - Disabling a virtual method should be illegal.
> 
> 	Arturo
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Steven Sharp
> Sent: Wednesday, July 18, 2007 11:35 AM
> To: sv-ec@eda.org; danielm@aldec.com.pl
> Subject: Re: [sv-ec] disable class method
> 
> 
>> From: "danielm" <danielm@aldec.com.pl>
> 
>> I cannot found  in LRM  statements describing if "disable" is allowed
> on
>> class method (task) and how it should work.
>>
>> I assume that if LRM doesn't forbid such usage so this is allowed, but
> I
>> still have doubts how it should work.
> 
> It is a task, so I agree that it would be allowed.  However, as with
> other re-entrant tasks, it isn't very useful.  This is because of your
> next question.
> 
> 
>> 1)
>> Generally there are 2 possibilities. Disable can work per object(*) or
> per
>> class(**).
> 
> As specified in the LRM, it will disable all invocations of the task.
> There is nothing special specified for class methods that changes this,
> and passing a different 'this' argument does not make it a different
> task.
> Regardless of the object used to reference it, they are all calling the
> same task.  I would expect the task name in a disable to be a static
> reference, so you wouldn't even need to specify an object in the
> disable.
> 
> I would expect the tasks in different specializations of a class to be
> considered different tasks.  Since any static storage that they used
> would
> be distinct, I would expect them to be distinct for this purpose also.
> This matches other tasks, where different instantiations of the same
> task,
> which therefore use different static storage, are distinct for
> disabling.
> The disabling mechanism was essentially static, and was left static when
> automatic tasks were added to the language.
> 
> 
>> 2)
>> Another question is what should happen if we try to disable method of
> an
>> non-existing object (below sample) - should it be runtime error(imho in
> case
>> we aprove disabling per object the it shoudl be runtime) or task called
> in
>> fork should be disabled in time 20 (this how it may work if we aprove
>> disabling per class)?
> 
> If it would be legal to reference a static property this way, then it
> should be legal to disable this way.  It is a static reference.  I would
> also assume that you could reference without an object, with something
> like "disable C::t", even for a task that is not a static method.
> 
> 
>> 3) 
>> The simplest possibility is to try disable static task - because it can
> be
>> done with :: operator. There is no problem with null references, and
> this
>> obviously works per class. So maybe disabling should be allowed only
> for
>> static methods? and should disable all task being  currently in
> progress
> 
> It would be best not to call it a "static task" if you mean "static
> method".
> A static task has static storage, and could be a static or non-static
> member
> of a class, or outside a class.  Conversely, a static method can be a
> static
> or automatic task.
> 
> Anyway, I agree that static methods are the simplest case, and I agree
> with your description of how this would work.
> 
> As I mentioned above, if disabling non-static methods is allowed, I
> would
> expect it to work the same way as static methods.  Since disabling does
> not require any access to any non-static members of the class, there is
> no need for an object.  If this seems too confusing, your suggestion of
> disallowing it for non-static methods may be a good idea.
> 
> Upon further thought, there is one situation where an object might get
> involved, and that would be virtual methods.  The actual type of the
> object might determine which implementation of the task would get
> disabled
> (i.e. the task declared in which base class).  This is so strange that I
> would support making it illegal.
> 
> 
> Steven Sharp
> sharp@cadence.com
> 
> 

-- 
--------------------------------------------------------------------
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.