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

Re: any type conversion

From: Cameron McCormack <cam@mcc.id.au>
Date: Tue, 20 Mar 2012 11:57:17 +1100
Message-ID: <4F67D5ED.6000607@mcc.id.au>
To: Marcos Caceres <marcosscaceres@gmail.com>
CC: public-script-coord <public-script-coord@w3.org>
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 

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 00:57:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:05 UTC