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." <[email protected]> wrote: > On Mon, May 20, 2013 at 7:55 PM, Domenic Denicola > <[email protected]> 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 > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
