- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 20 Mar 2012 11:57:17 +1100
- 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 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 00:57:47 UTC