On Wed, May 22, 2013 at 3:43 PM, Allen Wirfs-Brock
<[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
