On 2011-04-13 04:43, Cameron McCormack wrote:
Lachlan Hunt:
This seems to differ from the algorithm given for T[], which
requires that the object be either an array host object or a native
object, which would not handle the JQuery case. The sequence<T>
type seems more generic than that as the algorithm seems to be able
to support any object with a length and indexed properties.
Why wouldn’t it handle the JQuery case? Isn’t it a native object?
I didn't think so, but then perhaps I misunderstand what the spec means
by a native object. ECMAScript defines a native object as
"object in an ECMAScript implementation whose semantics are fully
defined by this specification rather than by the host environment."
So that would include things like Array, String, etc. I don't think
NodeList fits that definition, since it's provided by the host
environment, not ECMAScript.
I also thought something like this would not be a native object either:
function init() {
...
}
var x = new init();
JQuery more or less does that to create an object with custom
properties, and then basically uses Array.prototype.push.apply(x, elms)
to add the collection to that object.
The issue of whether you want to throw eagerly if passed an array with
elements of the wrong type to an operation taking a sequence<T> is an
interesting one, which probably still could bear some more discussion.
On the one hand, it helps ensure implementations don’t diverge based on
when during the course of running the method these elements from the
sequence are looked up. I could mean a lot of useless checks, though.
It's nice so that cases where authors try to pass in an array of things
that aren't nodes are handled well. The other alternative is just to
accept a collection of anything, and iterate through it to find all the
Element nodes, ignoring everything else. I don't see any reason to
prefer the latter approach.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
