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

Jing Tao tao at nceas.ucsb.edu
Fri Feb 17 12:57:50 PST 2006


Hi, Christopher:

Thanks for the replying even you are in vacation.

I vote 2 too. Now in order to create nil token (Except DoubleToken), I 
need create a XXToken with arbitrary value, then use nil() method (which 
come from Token class) to set this token to nil. This is not very 
convenience. But DoubleToken has a constructor to set nil value, it is very helpful to me 
to create nil DoubleToken.

Jing

Jing Tao
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101

On Fri, 17 Feb 2006, Christopher Brooks wrote:

> Date: Fri, 17 Feb 2006 12:26:00 -0800
> From: Christopher Brooks <cxh at eecs.berkeley.edu>
> To: Dan Higgins <higgins at nceas.ucsb.edu>, Kepler-dev at ecoinformatics.org
> Subject: Re: [kepler-dev] Token.toString method(s)
> 
> 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
>> *******************************************************************
>>
>>
>>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>


More information about the Kepler-dev mailing list