[kepler-dev] DateToken

[Christopher Brooks]

Hi Patricia,
I saw that you checked in ptolemy.data.DateToken, which is a copy of 
kepler/util/src/org/kepler/date/DateToken.java so that we can use 
DateToken in Ptolemy (outside of Kepler).  The biggest difference 
between the two is that the Ptolemy version is convertible from LongToken.

There was a FindBugs warning about ptolemy.dateToken.toString() 
returning null, so I fixed that.

I also added support for nil DateTokens, so that we can support missing 
data.  The Kepler version probably does not support nil DateTokens.

I also added tests for some of the above operations.  Unfortunately, 
Ptjacl does not handle longs very well, so writing Tcl unit tests is tricky.

The ptolemy.data.DateToken file was badly formatted, it could be that 
your Eclipse configuration is using tabs.  However, my guess is that the 
formatting issues were from the copy from Kepler.

A few open issues:

- In ptolemy.data.type.BaseType, we have:
> /** The date data type. */
>     public static class DateType extends BaseType {
>         private DateType() {
>             super(DateToken.class, "date");
>         }
>
>         public Token convert(Token t) throws IllegalActionException {
>             if (t instanceof DateToken) {
>                 return t;
>             } else if (t instanceof LongToken) {
>                 return new DateToken(((LongToken) t).longValue());
>             } else if (t instanceof StringToken) {
>                 return new DateToken(((StringToken) t).stringValue());
>             }
>             throw new IllegalActionException(
> Token.notSupportedIncomparableConversionMessage(t, "date"));
>         }
>
>         public int getTypeHash() {
>             return 15;
>     }
Isn't anything that is convertible to a LongToken losslessly acceptable 
here as well?

Isn't it possible to losslessly convert from a DateToken to a 
LongToken?  Will this mess up the lattice?

- In ptolemy.data.DateToken, you have an _isEqualTo() method and other 
methods, these are necessary because ptolemy.data.DateToken extends 
AbstractConvertibleToken.  However, there are a bunch of methods like 
_add(), _divide() etc. that have no method bodies.

- Certain operations, such as add, are clearly doable if the Dates are 
converted to longs and then added and then converted back to 
DateTokens.  I think _add() and _subtract() could be possible

- For _isCloseTo(token, double epsilon):     If we convert the two 
tokens to longs and the epsilon to a long, then this might make sense?   
However, double is not losslessly convertible to long? Probably throw an 
IllegalActionException here.

- I'm not sure it makes sense to divide a date by another date, but 
dividing a date by a long makes a certain amount of sense maybe?  I dunno.

- Ditto with _multiply.

- _modulo of two Dates might make sense but is confusing and should 
probably throw an exception.

Does anyone have thoughts about the above?

_Christopher

-- 
Christopher Brooks, PMP                       University of California
Academic Program Manager & Software Engineer  US Mail: 337 Cory Hall
CHESS/iCyPhy/Ptolemy/TerraSwarm               Berkeley, CA 94720-1774
cxh at eecs.berkeley.edu, 707.332.0670           (Office: 545Q Cory)