On 27/04/10 20:23, David Bruant wrote:
Le 27/04/2010 03:54, Geoffrey Sneddon a écrit :
On 26/04/10 19:50, And Clover wrote:
David Flanagan wrote:
Rather that trying to make DOM collections feel like arrays,
how about just giving them a toArray() method?
I like that, as a practical and explicit (JavaScript-specific)
binding.
In the longer term, what's the thinking on a more basic change:
- Require specific DOM interfaces like NodeList, HTMLCollection,
Element etc. to be available for prototype monkey-patching under
their interface names as properties of `window`?
Then we wouldn't have to worry about what Array-like methods need
to be provided on HTMLCollection, because application and
framework authors could choose whichever they liked to prototype
in.
IE8/Moz/Op/Saf/Chr already do this to a significant extent, but
there's no standard that says they have to. It would allow DOM
extension to be put on a much less shaky footing than the messy
hack Prototype 1.x uses.
Is this something that's a reasonable requirement for browsers in
future?
HTML5 through WebIDL and its ECMAScript binding already does
require this.
I can see where interfaces are expected to be exposed
([NamedConstructor]) in the global object, but I don't see where it
is said that the prototype of the constructor must be extensible. I
don't even see this in the section which is the relevent one in my
opinion (Interface prototype object) I have read this version of
WebIDL : http://dev.w3.org/2006/webapi/WebIDL/
Section 4.1.1 Interface object:
The interface object MUST also have a property named "prototype" with
attributes { DontDelete, ReadOnly } whose value is an object called
the interface prototype object. This object provides access to the
functions that correspond to the operations defined on the interface,
and is described in more detail in section 4.4.3 below.
--
Geoffrey Sneddon — Opera Software
<http://gsnedders.com/>
<http://www.opera.com/>
