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

# Erik Arvidsson (13 years ago)

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.

# Hemanth H.M (13 years ago)

Hoping to see that day soon! :)

# Brendan Eich (13 years ago)

Erik Arvidsson wrote:

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

How does Allen's strawman preclude these? You can have .foo and .bar by the usual means, as properties (lazy if proxied). You can alias indexes to them using @elementGet and @elementSet if those hooks are invoked for any bracket-indexed access, whatever the type of the expression in brackets.

# Erik Arvidsson (13 years ago)

On Tue, Jun 19, 2012 at 10:12 AM, Brendan Eich <brendan at mozilla.org> wrote:

How does Allen's strawman preclude these? You can have .foo and .bar by the usual means, as properties (lazy if proxied). You can alias indexes to them using @elementGet and @elementSet if those hooks are invoked for any bracket-indexed access, whatever the type of the expression in brackets.

With proxies, yes. But if you are already using proxies I don't see why you would use @elementGet and @elementSet?

# Allen Wirfs-Brock (13 years ago)

On Jun 19, 2012, at 10:34 AM, Erik Arvidsson wrote:

On Tue, Jun 19, 2012 at 10:12 AM, Brendan Eich <brendan at mozilla.org> wrote:

How does Allen's strawman preclude these? You can have .foo and .bar by the usual means, as properties (lazy if proxied). You can alias indexes to them using @elementGet and @elementSet if those hooks are invoked for any bracket-indexed access, whatever the type of the expression in brackets.

With proxies, yes. But if you are already using proxies I don't see why you would use @elementGet and @elementSet?

There are various differences between @elementGet and @elementSet and proxy get/set handlers. One is that the index value isn't coerced to a string before being passed to @elementGet/@elementSet

# Erik Arvidsson (13 years ago)

On Tue, Jun 19, 2012 at 10:45 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

There are various differences between @elementGet and @elementSet and proxy get/set handlers.  One is that the index value isn't coerced to a string before being passed to @elementGet/@elementSet

That's a good point.

For expressing the DOM APIs in JS this feature is not needed so I still stand by my point; If you are using proxies for DOM then you do not need to use @elementGet and @elementSet (for the current DOM APIs).

@elementGet and @elementSet are still useful for things like better collection APIs.

# Brendan Eich (13 years ago)

Erik Arvidsson wrote:

On Tue, Jun 19, 2012 at 10:45 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

There are various differences between @elementGet and @elementSet and proxy get/set handlers. One is that the index value isn't coerced to a string before being passed to @elementGet/@elementSet

That's a good point.

For expressing the DOM APIs in JS this feature is not needed so I still stand by my point; If you are using proxies for DOM then you do not need to use @elementGet and @elementSet (for the current DOM APIs).

But you don't need proxies if you don't have lazy reification of properties, and IIUC @elemnet[GS]et are enough to make both frames.foo and frames['foo'] work, along with frames[0] which might alias frames.foo.

IOW, proxies and @elementFoo are independent and can be used together or not. And @elementFoo can be used for string-named property identifiers as well as indexes. No?