Overriding Map/etc with get/set hooks?

Domenic Denicola domenic at domenicdenicola.com
Mon May 20 22:20:47 PDT 2013

Oh, I must have misread your original message. I thought it did not allow storing non-string keys. If it can allow storing any kind of key, like a Map, and it's just the initial data you're referring to, then maybe it is a Map. As long as the contract that `map.set(x, y); map.get(x) === y` works for any `x` and `y`, then you're probably fine.

On May 21, 2013, at 1:16, "Tab Atkins Jr." <jackalmage at gmail.com> wrote:

> On Mon, May 20, 2013 at 7:55 PM, Domenic Denicola
> <domenic at domenicdenicola.com> wrote:
>> Seems like this isn't really a Map? It'd be pretty confusing for something to pretend to be a Map but act in such coercive and side-effecty ways. Better to just obey the Map structural type, perhaps, to give people an interface they're used to while not pretending to be something you're not?
> Oh, no, "obeying the Map structural type" is much worse than even my
> bad solution of subclassing Map in my OP. It means I have to define
> bespoke versions of *all* the Map functions myself, rather than just
> the "basic" ones (and keep adding to the interface as ES adds to Map),
> functions added by the author to Map.prototype don't show up, it
> doesn't type as a Map with the ES methods of typing, etc.
> It's clearly a Map - it's a set of key/value tuples, which you can
> create/read/update/delete/iterate, exactly like the vanilla Map.  The
> only difference is that its [[MapData]], rather than being a
> freshly-created independent empty list upon creation, is a
> spec-defined list that reflects the data from another object.  This
> doesn't interfere with its operation as a Map, it just makes the
> get/set operations slightly more complex than they are for vanilla
> maps.
> ~TJ

More information about the es-discuss mailing list