[kepler-dev] Token.toString method(s)

[Dan Higgins]

Hi Christopher,
    I forget you were going on vacation. Are you staying in the 
Barcelona area? We were there several years ago and greatly enjoyed it.  
Have fun! (and don't waste vacation time worrying about 'Tokens'!)  ;-)

    I agree on you option #2.
   
    I might add that I find the expression 'nil token' a bit misleading. 
I prefer to express it as a 'token with the nil property' (or something 
like that) since I think that makes it clearer that any type of token 
object can be 'nil'. (i.e. nil is NOT a type like Boolean, Double, Int, 
etc.)

Dan

-----

Christopher Brooks wrote:

> Hi Dan,
> I'm on vacation, but I meditated on nil tokens while in the Barcelona 
> airport.
>
> The relationship between nil tokens and type is a little fuzzy to me.  
> It seems that nil
> tokens can really be of any type.  We need a way to create a nil token 
> and use that token
> in an expression and have the expression type check properly.  In 
> particular, if we
> have an array of doubles and one element is nil, we want to have a nil 
> token that will properly
> type check.  Tokens are immutable so I think we also need a way to 
> create nil tokens by
> construction.  This can get a little tricky.  I see two possible ways 
> of creating nil tokens:
> 1) Have a XXXToken(boolean) constructor that would set whether the 
> token was nil
> or not.  This is not so great for BooleanToken() though.
> 2) Have a XXXToken(Object) constructor where if the Object parameter 
> is null, then the
> token is nil.  If the Object parameter is non-null, then some tokens 
> (AWTImage) could do
> instanceof and try to use the parameter if it was the right type.   
> Perhaps Some tokens would just
> throw an exception if the perameter was non-null though.
>
> I'm leaning towards #2.  What do you think?
>
> Also, yes, I agree, we need to extend the toString() methods to handle 
> nil tokens.  Edward
> was not that opposed to modifying the Token classes to properly handle 
> nil tokens (Edward,
> correct me if I've been drinking to much Rioja and heard you wrong.)  
> We should try to
> make the checks for nil tokens very efficient though.
>
> Working on the nil token is probably at the top of my todo list, so 
> I'll be spending some time on it.
>
> _Christopher
> ----- Original Message ----- From: "Dan Higgins" <higgins at nceas.ucsb.edu>
> To: "Christopher Brooks" <cxh at eecs.berkeley.edu>; 
> <Kepler-dev at ecoinformatics.org>
> Sent: Friday, February 17, 2006 9:58 AM
> Subject: Token.toString method(s)
>
>
>> Hi Christopher,
>>
>>    Jing and I were looking over the Ptolemy code for the Token class. 
>> The 'toString' method does indeed return "nil" when there is a 
>> missing value. However, when you look at the code for derived token 
>> classes like IntToken or DoubleToken, each has its own version of 
>> 'toString' that overrides the Token base class. Don't we need to 
>> change the 'toString' method in all the derived classes to return 
>> 'nil' when the token is set to that? [If not, it makes the 
>> RExpression actor conversion much more difficult, especially for 
>> arrays of tokens.]
>>
>> Dan
>>
>> -- 
>> *******************************************************************
>> Dan Higgins                                  higgins at nceas.ucsb.edu
>> http://www.nceas.ucsb.edu/    Ph: 805-893-5127
>> National Center for Ecological Analysis and Synthesis (NCEAS) Marine 
>> Science Building - Room 3405
>> Santa Barbara, CA 93195
>> *******************************************************************
>>
>>
>>
>


-- 
*******************************************************************
Dan Higgins                                  higgins at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Ph: 805-893-5127
National Center for Ecological Analysis and Synthesis (NCEAS) Marine Science Building - Room 3405
Santa Barbara, CA 93195
*******************************************************************