On Tue, May 21, 2013 at 4:07 AM, David Bruant <bruan...@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 _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
