[kepler-dev] programatic access to class entity

Edward A. Lee eal at eecs.berkeley.edu
Wed Jul 27 11:57:53 PDT 2005


If a class is defined in a separate file, then changes to the class
will immediately propagate to any instances with the same JVM.
In another JVM, they will only propagate if the class definition
file is re-read (e.g., you start up a new instance of Kepler after
the class file has been modified).

If you have multiple instances of Kepler running at once, and make
changes to a class file, then they will not automatically propagate
to instances in the other running Kepler.

This could be fixed if it's an issue... All it would require is
that anytime a MoML file is read by an instance of Kepler, that the
instance of Kepler monitor that file for updates. I know this is
possible, since Eclipse does this...  I suspect Eclipse simply
polls the file, in which case there will have to be some decision
about how often to do this polling.

Edward

At 09:17 AM 7/27/2005 -0700, Shawn Bowers wrote:

>Hi Edward,
>
>Just out of curiosity, how do you track instances across multiple MoML 
>files? For example, if I define a class and store it in a particular MoML 
>file, then instantiate the class in multiple workflows (each stored in a 
>different MoML file), and I make a change to the original class, how does 
>this change propagate to the various instances?  Or, is a class only 
>identified within a particular context?
>
>It sounds like you say below that "any changes" made to the class will be 
>made to all the instances; so knowing how you track this would be 
>potentially useful to some of the Kepler implementations of KSW, etc.
>
>Thanks,
>shawn
>
>
>
>
>Edward A. Lee wrote:
>>The <class> tag is defined in section 2.7 of vol. 1 of the Ptolemy II docs.
>>An entity that is defined as a <class> can be instantiated many times,
>>without copying its contents. Any changes made to the class will be made
>>to all the instances. It can also be subclassed.
>>We call this mechanism "actor-oriented classes" to distinguish them
>>from the "object-oriented classes" of Java.  It brings the OO concept
>>of inheritance to actor-oriented designs.  There is a paper on it
>>at:
>>http://ptolemy.eecs.berkeley.edu/publications/papers/04/Classes
>>Edward
>>At 03:20 PM 7/20/2005 -0700, Chad Berkley wrote:
>>
>>>hey,
>>>
>>>does anyone know what the programatic difference is between an entity
>>>that is defined in moml as <entity> vs. one that's defined as <class>?
>>>I need to figure out the difference in the KSW builder, but i can't see
>>>where in the MoML API you can get information as (AFAICT) they both get
>>>instantiated as a ComponentEntity.  Basically, i just want to know how
>>>to tell the difference (programatically) between a stand alone workflow
>>>and a moml based composite actor.
>>>
>>>thanks,
>>>chad
>>>_______________________________________________
>>>Kepler-dev mailing list
>>>Kepler-dev at ecoinformatics.org
>>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>
>>------------
>>Edward A. Lee
>>Professor, Chair of the EE Division, Associate Chair of EECS
>>231 Cory Hall, UC Berkeley, Berkeley, CA 94720
>>phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
>>eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
>>_______________________________________________
>>Kepler-dev mailing list
>>Kepler-dev at ecoinformatics.org
>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev

------------
Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal  



More information about the Kepler-dev mailing list