On Jun 4, 2007, at 7:52 PM, liorean wrote:
On 05/06/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
I think DOM properties (and sometimes methods and function arguments)
vary on this. Some use the raw ECMAScript ToString algorithm. Others
additionally map the null value to the empty string instead of
"null". Still others map the undefined value to "undefined". Some do
both. I am pretty sure that for compatibility reasons you can't just
do the same for each, so we may as well just define and test the
legacy behavior for each one. Whatever is most common can be the
default, and others can be marked up in the IDL appropriately.
I know. But I think this should be very clearly specified in the DOM
specification and ECMAScript bindings, and more specifically I think
that the correct way to specify it is as follows:
Type conversions should follow the rules used for the specific
language. In the case of ES3:
- If the DOM requires a DOMString, since DOMString is mapped to ES3
String, the type conversion should be through ToString(value).
I agree it should be very clearly specified, but you can't specify
just a single rule. For historical reasons, different properties need
different rules. We need to specify a couple of different type
conversion rules and specify clearly which property uses which.
- If the DOM requires an unsigned long, the ES3 spec way of handling
this is to take ToNumber(value) and compare it to ToUInt32(value). If
not equal an ES3 TypeError should be thrown, if equal the return value
from ToUInt32(value) should be cast from Number to UInt32. (This
conversion is on the ES3 side of the function call, so for example
CharacterData.substringData would not throw INDEX_SIZE_ERR on negative
offset or count since the language conversion would already have
failed before the function was entered.)
Actually, it's important for compatibility and conformance with past
specs to throw INDEX_SIZE_ERR for some (but not all) properties
specced as taking unsigned but actually passed a negative value.
I just have to go back to my statement above. We need to investigate
current browser behavior and what past specs say, and keep in mind
that the same IDL type may in practice be mapped to a couple of
different conversion behaviors for ECMAScript. You can't decide this
based just on pure logicl
Regards,
Maciej
