- From: Cameron McCormack <cam@mcc.id.au>
- Date: Wed, 04 Jan 2012 13:15:37 +1100
- To: João Eiras <joaoe@opera.com>
- CC: public-script-coord@w3.org
João Eiras:
> First, both mention to [[Get]] the property of name length from the
> object and call ToUInt32 on the value. What happens if the object does
> not have a length property? Should a TypeError be thrown, or an array of
> length 0 assumed?
ECMA-262 says ToUint32(undefined) == 0. So an array of length 0 will be
assumed, yes.
> b)
> What happens is a function object is passed ?
> Example:
>
> # var f = new Function("arg1", "arg2", "code");
> # exampleFunction(f);
>
> Function objects have immutable lengths, but by default no indexed
> properties. Would it make sense for native function objects to throw a
> TypeError? Passing a function as an array would perhaps most likely be a
> programming error anyway.
Yes. As James pointed out, the overload resolution algorithm (as
recently changed) will throw a TypeError if you pass a Function object
in. Of non-platform objects, only typeof "array" objects can be passed
to sequence<T> arguments.
> c)
> According to the spec a String object would be converted into an array,
> by separating each character into each array position, because Strings
> by default have a length property, just like atomic strings, and indexed
> properties. However atomic strings aren't objects, hence the algorithm
> would fail.
>
> e.g.:
> # exampleFunction(new String("abc"))
> would convert the argument to
> # ["a","b","c"]
>
> Is this expected? It does seem completely overkill though given that
> strings internally are not really represented as an array of individual
> characters. It might be useful but would most likely be a programming
> error.
Yes, and the overload resolution algorithm will cause the above to throw
a TypeError.
Note that it's different for IDL attributes, where the overload
resolution algorithm is not invoked. There, you do get the more lenient
conversions like you mention above. But I will disallow those per my
reply to James.
Received on Wednesday, 4 January 2012 02:16:07 UTC