Modifying the type hierarchy in this way is difficult: We haven't yet implemented a good way to make it extensible in this way.
Part of the problem is that the type lattice is somewhat hardcoded into operations on the token classes. Modifying the type hierarchy in significant ways is not currently possible without modifying the existing token classes at the same time. I have some ideas on improving the situation, but I haven't had time to implement them yet.


The one way that the type hierarchy *can* be simply extended is that it allows the addition of new data types that are incomparable with
the existing types (other than UNKNOWN and GENERAL, of course). If you define a new Token class, and a corresponding type class, then this type will be correctly type checked.


There are other ways to get the behavior you desire.. One is through an (unimplemented) structured type called "Union" which operates similar Unions in C... This should be relatively easy to implement, we just haven't gotten around to it. Your type is then Union(double, event) or something similar.
Another way is to use side information (a boolean, for instance) to determin whether or not the "double" is valid.
Another way is to use a less constrained Model of Computation (like SR or DE) which has a built-in notion of absent.
Any one of these would probably be significantly simpler than modifying the existing double token....


Steve

At 11:08 AM 10/13/2003 -0700, Chad Berkley wrote:
Hello,

We have a question about the extensibility of the Ptolemy II type system. In our project, we need to extend the type system by adding new
data types and modifying the type hierarchy. As an example, we need to
incorporate a new double type (as a superclass of double) that accepts
null, or missing, values.


We would like to add new data types without altering the Ptolemy codebase. It seems the way to do this is by overriding the TypeLattice class (to add new edges for our new extended types). We had the impression (e.g., as discussed in Chapter 12 of the manual) that this extensibility was possible. However, it appears that the TypeLattice is hard coded, e.g., it is not a parameter to the BaseType class, and instead, a default instance of TypeLattice is hard coded into BaseType.

So, the questions are: Are our ideas using the Ptolemy type system code
in the way in which it was intended? Are there other ways to extend types without altering the Ptolemy code? Do you have any suggestions as to our approach?


thanks,
chad


-- ----------------------- Chad Berkley National Center for Ecological Analysis and Synthesis (NCEAS) [EMAIL PROTECTED] -----------------------


---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED]



---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED]

Reply via email to