W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: More questions about contextual reference nodes

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Wed, 13 Apr 2011 11:43:42 +0200
Message-ID: <4DA5704E.80903@lachy.id.au>
To: public-webapps <public-webapps@w3.org>
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
Received on Wednesday, 13 April 2011 09:44:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:19 UTC