[kepler-dev] web service actor

Edward A Lee eal at eecs.berkeley.edu
Mon Mar 1 17:40:07 PST 2004

The Ptolemy type system has a type for wrapping arbitrary Java objects.
The object is wrapped in an ObjectToken.

The intent of the ObjectToken class is to permit such experimentation,
but basically, the type system does nothing for you except ensure that
if you declare that a port has type ObjectToken, then it will get
an ObjectToken.  It doesn't do anything about the specific type...
You can do runtime checks when you receive an object token using

A pattern we've followed in the past is to use this for experimentation,
and then when we've settled on a useful class for exchanging data, then
declare an type for it...  It's quite easy to do that, as long as
the type isn't convertible to or from existing types...


At 09:58 PM 2/25/2004 -0800, Shawn Bowers wrote:

>I think another issue is if this kind of approach would be considered
>"circumventing" the Ptolemy type system.  Is it typical for an actor to
>pass token objects that don't have a corresponding Ptolemy type? And if
>so, what ramifications might this have on static type checking within
>Ptolemy and for enabling reusable actors (i.e., removing tight-coupling
>between actors)?
>It must be that the Ptolemy folks have considered the issue of allowing
>actors to pass arbitrary Java objects, otherwise, why even have a type
>system?  I guess that missing from the discussion/implementation is
>bringing it back to the underlying philosophy or design decision at work
>within Ptolemy concerning tokens, token types, the type lattice, and
>Ptolemy's static type checking. (I might just be speaking about my own
>ignorance on the issue here :-)
>P.S., I wouldn't necessarily say we were having a "heated" debate; more
>like a misunderstanding about what the real issue is/was -- at least it
>wasn't clear to me until the end of the discussion.

Edward A. Lee, Professor
518 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0455, fax: 510-642-2739
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal

More information about the Kepler-dev mailing list