- 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