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

Re: problems with §4.2.19 Arrays

From: Cameron McCormack <cam@mcc.id.au>
Date: Tue, 31 May 2011 16:14:27 +1200
To: David Flanagan <dflanagan@mozilla.com>
Cc: ms2ger@gmail.com, public-script-coord@w3.org
Message-ID: <20110531041427.GB6179@wok.mcc.id.au>
David Flanagan:
> First of all, a typo:
> >Array host objects MUST always have a property named ToString(i)
> >for every integer index 0 < i < n, where n is the length of the
> >array.
> That first < should be <=.

Thanks, fixed.

> More importantly this section says that the index properties and the
> length property of readonly arrays must be configurable: false.

I think I did that initially for simplicity.

> DOM Core says that the attributes property of an Element object is a
> readonly Attr[].

Interesting.  In previous versions of DOM Core that was a NamedNodeMap.

> Historically (I'm not sure if DOM Core mandates this, though) each
> reference to the attributes property returns the same object.

I’d believe that.

> And although user code cannot change the length or set the elements,
> those may change between accesses.

Right.

> That is, the attributes object is live.   I can't implement live but
> non-configurable properties in JavaScript (even with Proxies).  And
> I can't implement it in C++ without violating §8.6.2 of the ECMA-262
> spec.

I’m not even sure that changing the NamedNodeMap to an array type is
what we should be doing, here.  I would be surprised if there isn’t code
on the web that calls item() or any of its other methods, which you
wouldn’t have if it’s an array host object.

But to the point about implementability of array host objects in general
(since there are a couple of other uses currently dotted around web
platform specs), I think we should just expose these properties in the
same way that indexed properties are exposed – so in whatever way comes
out of the earlier thread on this mailing list (probably simple custom
[[Get]] etc. hooks).

> §3.7.18 of WebIDL says:
> 
> >Arrays can either be fixed length or variable length. Fixed length
> >arrays cannot have their length changed by user code after they
> >have been created, while variable length arrays can. Unless
> >otherwise specified, arrays are fixed length.
> >
> >Arrays can also be designated as being read only. User code cannot
> >modify the values of read only array elements. If an array is read
> >only, then it is also implicitly fixed length
> ><http://dev.w3.org/2006/webapi/WebIDL/#dfn-fixed-length>.
> >
> 
> Since this text explicitly mentions user code, I suspect that live
> read-only-but-unfrozen arrays are supposed to be possible and that
> this is simply a bug in WebIDL.

Yeah.

> On the other hand, maybe DOM Core just needs to change attributes
> back to a NamedNodeMap?

I think so.  CCing Ms2ger.

-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Tuesday, 31 May 2011 04:15:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:03 UTC