Decoupling [ ] and Property Access and the DOM (Was: Why not NodeList#forEach :\?)

Erik Arvidsson erik.arvidsson at gmail.com
Tue Jun 19 09:31:42 PDT 2012


On Tue, Jun 19, 2012 at 8:37 AM, Allen Wirfs-Brock
<allen at wirfs-brock.com> wrote:
> Actual API "design" is probably an orthogonal issue.  What the "Object Model Reformation" proposal (which is probably better understood by its subtitle "Decoupling [ ] and Property Access") does is permit the existing behavior of DOM collections to be directly expressed in JavaScript without having having to resort to host object magic.  It supports the general principle of: If the DOM needs to do it then it should be doable in pure JavaScript.  There are lots of reasons why for some objects it makes sense for "indexed access" to have different semantics than "property access".  The DOM does this today. In an improved DOM API design it will probably also be the case.  The Object Model Reformation provides a semantic basis for designing such improved APIs rather than just making up host object magic that has no foundation in core JavaScript semantics.

I'm a big fan of your proposal but it is unfortunately not sufficient
to express the current DOM. People do depend on MemberExpression too.
For example:

document.forms[0].bar instead of document.forms[0]['bar']
frames.foo instead of frames['foo']

One thing we could do once/if the object model reformation is
implemented is to rename the current indexed and named properties in
WebIDL to LegacyIndexed and LegacyNamed and mandate that new
interfaces only use MemberLookup (square bracket lookup).

Still, I wonder if we don't need an alternative way to implement
indexed and named attributes from WebIDL to compatible with the web as
is its.

-- 
erik


More information about the es-discuss mailing list