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`. Ron ________________________________________ From: es-discuss-boun...@mozilla.org on behalf of Tab Atkins Jr. Sent: Friday, May 24, 2013 5:08 PM To: Jason Orendorff Cc: EcmaScript 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.orendo...@gmail.com> wrote: > On Fri, May 24, 2013 at 12:02 PM, Tab Atkins Jr. <jackalm...@gmail.com> > wrote: >> On Fri, May 24, 2013 at 9:27 AM, Jason Orendorff >> <jason.orendo...@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 >> for >> >> 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 way. ~TJ _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
