Non-generic traps for non-generic objects (was: Overriding Map/etc with get/set hooks?)
rbuckton at chronicles.org
Fri May 24 14:35:25 PDT 2013
Another way to look at this is that there is no way to prevent a caller from using methods from the superclass on a subclass. In other OO languages, its much harder (or nearly impossible depending on the language) to forcibly call a superclass method against a subclass that has been overridden by the subclass.
Tab wouldn't have this issue if there were a way to prevent an external caller from executing Map.prototype.set.call(mapSubclass) if the mapSubclass overrides `set`.
From: es-discuss-bounces at mozilla.org on behalf of Tab Atkins Jr.
Sent: Friday, May 24, 2013 5:08 PM
To: Jason Orendorff
Subject: Re: Non-generic traps for non-generic objects (was: Overriding Map/etc with get/set hooks?)
On Fri, May 24, 2013 at 11:53 AM, Jason Orendorff
<jason.orendorff at gmail.com> wrote:
> On Fri, May 24, 2013 at 12:02 PM, Tab Atkins Jr. <jackalmage at gmail.com>
>> On Fri, May 24, 2013 at 9:27 AM, Jason Orendorff
>> <jason.orendorff at gmail.com> wrote:
>> > Counterproposal: address this in WebIDL. Add a magic [Maplike] tag that
>> > means something like: [...]
>> [...] It's not the *best* solution, because the easy magic is only there
>> spec authors, but it's the best so far.
> I see your point. I think this is a case where spec authors definitely have
> a problem, but JS programmers will not sweat it that much.
> In JS it's just so easy: https://gist.github.com/jorendorff/5645591
That's only "easy" because we can assume that authors will manually
adjust their code when we add more Map methods, or if they want to add
their *own* Map methods. That's the exact thing I'm complaining
about, except that we can't assume that specs will get updated in this
es-discuss mailing list
es-discuss at mozilla.org
More information about the es-discuss