- 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