On Wed, May 22, 2013 at 3:40 AM, Brendan Eich <[email protected]> wrote: > There aren't many Map methods. Write your own workalikes if you need 'em. > Done.
Really? You're seriously saying that I, and every other spec author, every time we need to spec something that's just like a built-in collection class but has a type restriction or some other little tweak, should just reinvent Map/Set/whatever? I refuse to believe you're actually saying that, because of how bad it is for authors. This is a textbook example of elevating theoretical purity over spec authors and web authors. Does this mean that every time an author needs a Map, but only needs string keys, they should reinvent Map as well? Or is it just because the platform actually needs to enforce the restriction, and authors are allowed to >> All of these follow from the basic statement that *this is a map*, >> because it clearly is. > > Circular arguments won't help here. A Map doesn't have throw-on-certain-key > behavior; a Map doesn't act at a distance on other data without > metaprogramming. > > You've falling into a nominal typing trap. JS doesn't have a Map that > everyone must bend or break to suit quasi-Map-like use-cases, any more than > Array must be directly bent (or hooked with @@coerceKey trash) to be a > NodeList. > > Make a different data structure (it can subclass if you insist; it could > instead use Map internally). It's a map (that is, a weakly ordered store of key/value pairs). It happens to have a type restriction, but as long as you stay within that type, every Map invariant you can think of is maintained exactly (and we wouldn't throw, we'd toString). It also happens to have a linkage with another data structure, but that other structure is under the authors' complete control, so in practice it just means that there are two get/set/etc methods with slightly different signatures. ~TJ _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
