RE: [sv-ec] package classes and anonymous programs

Mike,

At the recent face2face meeting we discussed and have a preliminary
agreement that the scheduling should be based on the process call graph
rather than where the class is defined or the object is instantiated.
This is different from the way the 1800-2005 LRM defines scheduling, but
it does resolve a number of ambiguities and outstanding issues.

And, you are correct that if we apply the new (call graph) definition,
the only effect of an anonymous program would be to hide the declaration
from modules and interfaces. 

As for you last question, if the class is instantiated in a module and
the method is called from a program, the method call would indeed work
just like calling module tasks or functions from the program without
regard on whether the class properties are module or program variables.

	Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Michael Burns
Sent: Monday, November 20, 2006 2:03 PM
To: sv-ec@eda-stds.org
Subject: [sv-ec] package classes and anonymous programs


Hi folks,

When defining classes in a package intended for use in a program, is
there any 
need to use an anonymous program? I found an opinion in the email
archives that 
active vs. reactive scheduling of events created by calling class
methods should 
be determined by where the class is instantiated (program or module),
rather 
than where it's defined, but the 1800-2005 LRM itself seems silent on
the matter 
(so far as I have been able to determine). Mantis seems broken at the
moment 
(can't connect to database), so I couldn't search there.

If it is the object context rather than the class definition context
that 
determines execution semantics, then the only effect I can think of that
the 
anonymous program provides is to hide the definition from modules and 
interfaces; is this the case?

Another monkey wrench I just though of: what if the class is
instantiated in a 
module and the method is called from a program? My guess would be that
the 
method call would work just like calling module tasks or functions from
a 
program, treating the class properties as module variables.

I have a feeling these issues have been discussed before; if there are
old 
emails or other materials my searches haven't managed to find, a few
pointers 
would make me happy.

Thanks,
Mike Burns
Freescale