Decoupling [ ] and Property Access and the DOM (Was: Why not NodeList#forEach :\?)
Hoping to see that day soon! :)
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.
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?
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
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.
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?
On Tue, Jun 19, 2012 at 8:37 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
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.