W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2012

Re: any type conversion

From: Marcos Caceres <marcosscaceres@gmail.com>
Date: Tue, 20 Mar 2012 09:37:47 +0000
Message-Id: <5391CFC8-39B7-4B84-A5B1-0C594280673E@gmail.com>
Cc: public-script-coord <public-script-coord@w3.org>
To: Cameron McCormack <cam@mcc.id.au>
Heh, seems I had it backwards from the text. Will try again today :) going to be sending feedback as I go. Hope not to be too annoying. 

Sent from my iPad

On Mar 20, 2012, at 12:57 AM, Cameron McCormack <cam@mcc.id.au> wrote:

> Marcos Caceres: > I don't know what you mean by an object reference to a "special object"? And clearly, the above code doesn't seems achieve anything useful… So I'm not able to understand what you want me to implement there:(
> 
> There is no IDL type that has "undefined" as a value, but if you have for example
> 
>  interface A {
>    attribute any data;
>  };
> 
> and you do
> 
>  myA.data = undefined;
> 
> you would expect undefined to come back from getting that property again.  (Assuming all the property does is return what was set to it before!)
> 
> When JS values are passed to something expecting "any", it must determine what the actual IDL type it will be converting it to is.  If you pass a JS Number it will choose the IDL double type, if you pass a JS object reference, it will choose the IDL object type.  Because there is no IDL type that natively has a value meaning "undefined", I chose to convert JS undefined values to an IDL object value which is a reference to a unique (internal) object that represents the JS undefined value. When converting from an IDL object type back to a JS value, if the object reference is to this unique object than JS is handed back an actual undefined value again.
> 
> There shouldn't be a way to observe this special object value.  It's kind of a convenience (for me) to avoid adding a whole new type to the IDL that has "undefined" as one of its real values.
> 
>> Also, it's confusing that the algorithm is not written in terms of types (i.e., values derived from Type(x) in ECMAScript). If it was, may make things a bit more clear.
> 
> You might be right, but I think it is reasonably clear what "A Boolean value" means with regard to ECMAScript values.
Received on Tuesday, 20 March 2012 09:38:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:05 UTC