Overriding Map/etc with get/set hooks?
brendan at mozilla.com
Wed May 22 09:44:33 PDT 2013
On May 22, 2013, at 5:10 PM, "Tab Atkins Jr." <jackalmage at gmail.com> wrote:
> On Wed, May 22, 2013 at 3:44 AM, Brendan Eich <brendan at mozilla.com> wrote:
>> Tab Atkins Jr. wrote:
>>> 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.
>> Whining about TC39 like this is bad for business. Should I whine about W3C
>> to even up the bad karma?
> Please, *please*, let's drop the silly turf war rhetoric, it's
My point, your move. I did not bring it up, and I wrote the above rhetorical question solely to get you to cut it out.
>> But there's no free lunch. Either Map needs hooks lumbering its spec and
>> implementations for all users, or you need to do the hooking. Without
>> evidence that others need the hooking, as Allen argues, the burden's on you.
>> Buy your own lunch.
> The evidence for needing hooking is all around. We need maps and sets
> and array *all the time* in DOM and CSSOM and other specs, it's just
> that we usually lumber around and invent crappy versions of them
> because they didn't exist in JS before. Look at dataset. Look at
> CSSStyleRule. Look at my example. I could just iterate through specs
> and find examples all day where we've done something dumb because of
> the lack of a good, standardized data structure, but I don't think you
> actually need me to do that; you're familiar enough with the mistakes
> the web platform has made.
NodeList extends Array now but is not literally Array plus hooks. Same for Map and the quite different thing you're specifying.
OOP has not been replaced by HookOP.
Tom Van Cutsem's reply is on target: do not add unstratified traps to common base classes. Do use compositional and general-purpose extension mechanisms in ES6, including classes.
More information about the es-discuss