RE: [sv-ec] disable class method

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

LRM clearly defines that you can refernce by "::" operator only to static
properties and static methods. It should be explicitly defined in LRM if
there are any exeptions

>  If this seems too confusing, your suggestion of disallowing it for
non-static methods may be a good idea.
> 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.

If so then this also should be explicitly defined by LRM


DANiel

-----Original Message-----
From: Steven Sharp [mailto:sharp@cadence.com] 
Sent: Wednesday, July 18, 2007 8:35 PM
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


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