[kepler-dev] [Bug 2240] - add support for null values to data passing among ports

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2240


cxh at eecs.berkeley.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED




------- Comment #9 from cxh at eecs.berkeley.edu  2006-04-13 12:03 -------
I'm marking this bug as fixed, because I think the work here is done.
If there are problems, it can be reopened.

One thing that bothers me is that now we have a number of places where
we check to see if the token is nil when doing operations on tokens.
Will this slow things down?  The way we check for nil is by checking
to see if the token in question is == to the NIL token, so this should be
very fast.  I tried to think of different ways around this, such
as creating a subclass of each token that was NIL (IntTokenNil).
However, ScalarToken._doAdd() would still need to check for Nil-ness,
so no gain there.  I dunno . . 

Also, currently equals() returns false called on a NIL Token.
In otherwords, IntToken.NIL.equals(IntToken.NIL) returns false.
I'm not sure if this is right.  IntToken.NIL.isEqualTo(IntToken.NIL)
should return false, since the values of NIL tokens are not comparable.
But, should equals()?

Below is a summary of some of the design decisions that I sent in email
to kepler-dev.  

Many thanks to Dan, Jing, Tristan, Edward and everyone else for helping with
the Nil Token work.

_Christopher
> [Tristan wrote]
> > You mentioned in a previous email that you used to have nil-ness as
> > a property of the token rather than a state like the current
> > implementation. What were the problems with this system?
>
> When we reviewed the code, Edward suggested a NIL instance of
> the token instead of using a method to set a flag.
> The advantage of using a NIL instance is that we don't add a boolean
> to each Token.  Another advantage is that to check if a token is
> nil, we check to see if it is equal to NIL instead of checking
> a boolean, which is probably faster.
>
> One disadvantage is that the XXXToken(String) constructor can no
> longer be used to create a nil token because the constructor can't
> return a different instance.  We'd like something like:
>
>     public FooToken(String init) {
>         if (init.equals("nil") {
>           return Token.NIL;
>         }
>     }
>
> but that won't work because the constructor can't return a different
> instance.  Thus, the String constructors don't support constructing
> nil tokens.
>
> Also, each Token needs to have its own NIL because the convert()
> method returns a more specific type than the type of the argument, so
> we have to have IntToken.NIL instead of Token.NIL:
>
>     public static IntToken convert(Token token) throws IllegalActionException\
 {
>         ...
>         if (token == null || token.isNil()) {
>             return IntToken.NIL;
>         }
>
>
> Also, I had to introduce a type called niltype, (to differentiate it
> from nil).  Token.NIL is of the niltype, which is losslessly
> convertible to UnsignedByteToken, BooleanToken, IntToken, LongToken
> and DoubleToken.  The reason this is safe is because any operation
> that is performed on a NIL token usually results in a NIL.  Some
> operations, such as average, could choose to ignore the NIL token.
> In general, if you have a NIL, it can be seen as being of any type and
> thus it can be losslessly converted in to other types that have
> NILs.
>
> One other restriction is that the MatrixTokens do not support nil
> elements.  The reason is that MatrixTokens are to be used for places
> where speed is needed.  The underlying element type in a MatrixToken
> does not have support for nil types.  For example IntMatrixToken has
> an int[][] matrix behind it.  To support nil tokens here, we would
> need to add sparse matrix that would note which elements are nil.
> This could be done, but it points to creating classes that extend
> XXXMatrixToken rather than modifying the base XXXMatrixToken and
> getting a speed hit.
>
> Another issue is that NIL StringTokens have the toString() value
> "nil", yet constructing a StringToken with new StringToken("nil")
> results in a StringToken with three letters, n, i and l, which is
> not a NIL token.  Also, for historical reasons, new StringToken(null)
> returns a StringToken of length 0, aka the empty string.
> Currently, new StringToken(null) could not return StringToken.NIL
> anyway, but it seems odd.