Re: [sv-ec] disable class method

So, why not make a decision on that aspect in the LRM?  It seems
reasonably obvious to me that "disable" targets a specific task --
if the task addressing goes through a virtual reference to the
actual task that should be fine.

Gord.

Arturo Salz wrote:
> Gord,
> 
> The reason for disallowing disable on virtual methods is because it is
> not clear whether the disable should be applied to the actual method -
> what you refer as the branch - or to the base class method, meaning all
> implementations of a particular method.
> 
> 	Arturo
> 
> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
> Sent: Wednesday, July 18, 2007 4:40 PM
> To: Arturo Salz
> Cc: Steven Sharp; sv-ec@eda.org; danielm@aldec.com.pl
> Subject: 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.