Overriding Map/etc with get/set hooks?

Tab Atkins Jr. jackalmage at gmail.com
Tue May 21 10:52:51 PDT 2013


On Tue, May 21, 2013 at 7:19 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> On Tue, May 21, 2013 at 6:52 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
>> On Tue, May 21, 2013 at 12:19 PM, Brendan Eich <brendan at mozilla.com> wrote:
>>> Of course, coercing key type makes the API not Map. So if the
>>> bi-directionality is important, this would be a custom Map-like class.
>>
>> I guess I also do not really get this. Sure JavaScript does not have a
>> type system (yet?), but it seems that placing restrictions / coercion
>> on input does not invalidate any of the properties of a map other than
>> that there's a restriction on what goes in the map. To me that seems
>> very much like a subset of a map and all generic functionality written
>> around maps would work on such a map.
>
> The following function returns true for all Maps M, Strings k, and JS values v:
>
> function check(M, k, v) {
>    M.set(k,v);
>    return (v === M.get(k));
> }
>
> In fact, this is the essence of what Maps are about.  Your proposal
> doesn't have this property. Therefore, it shouldn't be a Map.

Within the type constraints we enforce, this is maintained.  That is,
if you use string keys and values, it maintains *all* of the Map
invariants.  If you use non-string keys or values, we coerce to a
string first, so the invariants may not hold in all circumstances.
That's the point of coercion.

This argument is like saying that, if "p.foo = obj; p.foo === obj;"
isn't maintained, then "p" isn't an Object and should be something
else.  In reality, we're completely fine with "foo" being a getter or
setter with arbitrary effects; in particular, it can apply coercion
rules, which is rather common on the web.

If TC39 isn't going to allow us to ever use *any* of the built-in
collection classes just because we have type restrictions we need to
enforce, that'll be a pretty raw deal for authors.  It'll just mean we
continue with our "custom, shitty, incompatible versions of all your
standard collections" thing that we've been doing for some time. (And
never doubt, for each collection you have, we'll have N slightly
incompatible versions, where N is proportional to the number of specs
that use something like the collection.)

> The analogy to NodeList is actually valuable -- NodeLists are pretty
> different from Arrays, but some of the array generics work on them. If
> the problem is that the Map functions should be more generic, that's
> something that could be fixed, but that doesn't mean we should pretend
> that things are maps when they aren't.

Making the methods more generic won't help much (though it would
probably help *slightly*) - the problem is that the methods *aren't on
the objects*.  Try to guess the relative numbers of people who do
"Array.prototype.forEach.call(arrayLike, ...)" versus the numbers who
just do a quick "Array.prototype.slice.call(arrayLike)" at the
beginning and then rejoice at having a real Array to use.

We need to fix this "type coercion means it's not one of ours"
problem, now.  It's not good for authors or for the platform as a
whole.

~TJ


More information about the es-discuss mailing list