Non-generic traps for non-generic objects (was: Overriding Map/etc with get/set hooks?)

Sam Tobin-Hochstadt samth at ccs.neu.edu
Fri May 24 15:22:12 PDT 2013


On Fri, May 24, 2013 at 5:52 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Fri, May 24, 2013 at 2:35 PM, Ron Buckton <rbuckton at chronicles.org> wrote:
>> 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`.
>
> Sure, but that's attacking it on the wrong level, I think.
>
> The problem is that the Map#set method grabs an *internal property*,
> bypassing Proxies, etc., so you can't defend against it.  If I could
> intercept access to [[MapData]] via proxy traps (like David suggests
> in the OP), everything would be *perfect* - every single problem I
> have would be resolved successfully, as would every additional
> possibility that Jason brings up.

Are you suggesting that the authors of JS abstractions should never
use private state because then subclasses couldn't modify the behavior
of that internal state?

Sam


More information about the es-discuss mailing list