On Tue, May 21, 2013 at 7:19 AM, Sam Tobin-Hochstadt <[email protected]> wrote: > On Tue, May 21, 2013 at 6:52 AM, Anne van Kesteren <[email protected]> wrote: >> On Tue, May 21, 2013 at 12:19 PM, Brendan Eich <[email protected]> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
