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

Tab Atkins Jr. jackalmage at gmail.com
Fri May 24 18:18:37 PDT 2013


On Fri, May 24, 2013 at 3:22 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> 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?

Kinda.  ^_^  But no, in practice, private state is usually just fine.
The problem here is that the "private" state in the Map makes it hard
for other specs to define alternate types of maps.

~TJ


More information about the es-discuss mailing list