Overriding Map/etc with get/set hooks?

Tab Atkins Jr. jackalmage at gmail.com
Wed May 22 11:09:01 PDT 2013

On Wed, May 22, 2013 at 10:35 AM, David Bruant <bruant.d at gmail.com> wrote:
> Le 22/05/2013 19:02, Tab Atkins Jr. a écrit :
>> On Wed, May 22, 2013 at 9:44 AM, Brendan Eich <brendan at mozilla.com> wrote:
>>> NodeList extends Array now but is not literally Array plus hooks. Same
>>> for Map and the quite different thing you're specifying.
>> NodeList is an interesting case, actually.  It's an Array, but with a
>> type restriction.
> I'm a bit lost here. What exactly do you label as "Array"? What is a "type
> restriction"?
> For sure, Array.isArray(anyNodeList) === false
> So the ES spec seems to disagree with the statement "a NodeList is an Array"
>> Live NodeLists even have basically the same linkage
>> behavior I'm talking about.
>> What do I need to do to get a Map like that?
> Proxy is the answer to your question (FWIW I've made a proxy-based
> implementation of arrays a while back [1]). But both cases can't really be
> compared.
> From a dev perspective, the interface of an array is its own properties
> (numerical up to 2^32-1, connection with the .length property...) and the
> interface of a map is the methods/accessors on the prototype ([[MapData]]
> being "just" a spec tool that could be replaced by anything else as long as
> prototype methods were behaving observably the same)

I don't agree; if that were the case, the return value of
querySelectorAll() would be adequate for my uses.

The interface of an array is also the Array methods.  Those are the
valuable things to copy, and it's why every time I write a non-trivial
webpage, I include at the top:

function findAll(sel) { return [].slice.call(document.querySelectAll(sel)); }

Array are damned useful. Things that do a crappy duck-typing of Arrays
by just exposing indexed properties and a .length property... not so

> If your object can have *any* property name, that can shadow the get/set/has
> property you need to interact with your map. I'm not sure what the solution
> is, but a proxy doesn't sound like a good idea at least because of the
> shadowing issue.

I think you may misunderstand my OP.  The *current* interface I have
defined in my spec is an arbitrary getter/setter/etc that can take any
property name (an "object map"), because that's easy to write and
manage in WebIDL.  I'd like to move to using a Map, because it's more
useful for authors, and it avoids all the issues with shadowing or
properties set on the prototype.


More information about the es-discuss mailing list