Overriding Map/etc with get/set hooks?

Tab Atkins Jr. jackalmage at gmail.com
Wed May 22 16:22:24 PDT 2013


On Wed, May 22, 2013 at 3:43 PM, Allen Wirfs-Brock
<allen at wirfs-brock.com> wrote:
> On May 22, 2013, at 7:21 PM, Tab Atkins Jr. wrote:
>>> -ride the same number of @@ methods so I don't see a major gain in that approach.
>> [[MapData]] is just a list of tuples.  All I need for my spec (and for
>> future specs that want something Map-like) is the ability to define my
>> own list of tuples (linked to another object), and the ability to
>> intercept sets/deletes so I can do coercion and adjustment of other
>> objects.
>
> [[MapData]] is a specification abstraction for an implementation chosen data structure.  The spec. only describes the semantics that it must be able to represent.  It is not necessarily (and hopefully isn't) implemented as a list of tuples. Regardless, it is only directly accessible at the implementation level of a ES engine.  Neither you or anybody else can directly interact with it.  However, you can indirectly interact with  [[MapData]]  through the built-in [[MapData]] methods.

Right; of course the implementation won't be a list of tuples, but the
spec description is.


>> Unless I'm completely missing something, there are at most 4 "basic"
>> things to override, the same 4 things that you override to make an
>> "object map": create/read/update/delete.
>>
>> Is it really more complicated than this?  If so, how?
>
> as complicated as this:
>
> class StringMap extends Map {
>    delete(key) {return super(String(key));
>    get(key) {return super(String(key));
>    has(key) {return super(String(key));
>    set(key, value) {return super(String(key), value));
> }

That works great until someone does "Map.prototype.set.call(strmap,
obj1, obj2)", at which point the map is corrupted.  You cannot
guarantee invariants via simple subclassing.  You have to hook the
four "underlying" operations, which all the rest are defined on top
of.

~TJ


More information about the es-discuss mailing list