[kepler-dev] DateToken

[Daniel Crawl]

Hi Christopher,

Since the Ptolemy DateToken is in the type lattice and has
more functionality than the Kepler DateToken, I don't see
any reason to keep the latter. I'll remove it and update the
Kepler references.

   --dan


On 6/22/14 7:39 PM, Christopher Brooks wrote:
> 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
>