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

Tab Atkins Jr. jackalmage at gmail.com
Tue May 21 11:00:23 PDT 2013


On Tue, May 21, 2013 at 4:07 AM, David Bruant <bruant.d at gmail.com> wrote:
> David Bruant wrote:
>> Le 21/05/2013 04:06, Tab Atkins Jr. a écrit :
>> > (One way to do this today is to subclass Map and provide my own
>> > get/set/etc. functions, but I need to override a potentially-open set
>> > (anything that doesn't directly lean on my overridden functions), and
>> > it doesn't prevent people from directly twiddling my [[MapData]] by
>> > calling Map.prototype.set.call() on my object.)
>> If you want to keep control over how people interact with your key/value
>> interface, a proxy seems more appropriate. It's been designed so that
>> you have full control and can't be bypassed.
>>
>> Although the behavior Map.prototype.set.call(someProxy) isn't very clear
>> yet spec-wise [1] you can be sure that it won't be possible to freely
>> mess around an internal [[MapData]] (because it would open an undesired
>> communication channel)
>
>
> Would it make sense to add specific traps for specific objects (Date would
> have some specific traps, so would objects with [[MapData]], so would
> objects with [[SetData]], etc.)?
> Very much like functions currently have some traps that only apply to them.

I'd be okay with this, if it lets me write something nice and simple
in WebIDL like I can do today with getter/setter/etc to define the
basic proxy operations.
<http://dev.w3.org/2006/webapi/WebIDL/#idl-named-properties>

Something like a [MapClass] tag on the interface, which puts Map on
the prototype chain, and mapgetter/mapsetter/mapcreator/mapdeleter
special operations.

(We'd want to go ahead and introduce the same for Set while we're at
it, obviously.)

~TJ


More information about the es-discuss mailing list