[kepler-users] Persistent objects, also: array element setting

[Edward A. Lee]

At 02:37 PM 2/20/2006, Maurice Yarrow wrote:
>Does anyone have a simple example of a Java class that can be used 
>in a workflow model for persistent object data.  Is this an actor, 
>in this case ?

An atomic actor is a Java class.

You can also carry an arbitrary Java object in an ObjectToken,
which can be passed between actors (subject to the actors' type
constraints).

Possibly interesting is a special actor that Xiaojun Liu created
called ClassWrapper. This actor has not be used much, so it may
have some rough edges (e.g., you have to set types of the ports
manually), but it could be useful.  The doc for it says:

  This actor wraps (an instance of) a Java class specified by the
  <i>className</i> parameter. The actor has no ports when created.
  If an input port is added to the actor, the name of the port is
  interpreted as the name of a method of the Java class. When the
  actor is fired and a token is received from this input port, the
  value of the token is treated as the argument(s) for invoking
  the method. If the method has a return value and the actor has
  an output port named <i>methodName</i>Result, the return value
  is wrapped in a token that is sent to the output port.


>If it is possible to have such persistent data obj, how is it 
>referenced/designated from within actors ?  Could it be referenced 
>from within the Expression operator ?

I don't think there is any way to reference either an actor or
an ObjectToken from within a Ptolemy expression.  This could be a
useful extension to the expression language, but it would be helpful
to see a concrete use case.  I can't imagine how to use this...

Of course, you can always write a custom actor (which is easy to do),
and it can reference an ObjectToken using ordinary Java code.


>I guess along the same lines is the following question I have been 
>meaning to ask for a while.  How does one set a particular (indexed) 
>array element in an already declared array ?  I presume that this 
>not possible due to the rule of token immutability.  Is this so ?

Correct. Nonetheless, there ought to be an actor like
ArraySetElement that yields a new array with one element replaced.
This is an oversight in the array library... I'll write it if I get
a chance (or, anyone else want to volunteer?).



>If it is not possible to set an array element, then I take it that 
>the only way is something like:  get the subarrays that are 
>respectively below and above the element to be set, and then use the 
>Append array actor to create a new array from the following three arrays:
>
>{ E1,...,En-1 }   { En (new val) }  { En+1,...,Enmax }
>
>This is a tiny bit ugly, no ?

Yes, this would be ugly.  ArraySetElement would be better.

Note that you can get around the immutability of tokens with ObjectToken,
where there is no way we can enforce immutability. However, you must be
very careful doing this.  Immutability is there for a good reason.
Without it, none of directors would implement a determinate model
of computation.  In other words, there could be more than one correct
execution of model, and different executions would yield different
results.

Edward


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