Overriding Map/etc with get/set hooks?
Tab Atkins Jr.
jackalmage at gmail.com
Wed May 22 08:58:52 PDT 2013
On Wed, May 22, 2013 at 3:40 AM, Brendan Eich <brendan at mozilla.com> wrote:
> There aren't many Map methods. Write your own workalikes if you need 'em.
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
> 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
> 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.
More information about the es-discuss