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

David Bruant bruant.d at gmail.com
Tue May 21 04:07:30 PDT 2013


Hi,

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.

David


More information about the es-discuss mailing list