Overriding Map/etc with get/set hooks?

Tab Atkins Jr. jackalmage at gmail.com
Mon May 20 19:06:06 PDT 2013


For the CSS Variables spec I need to define an object with arbitrary
string keys, with the initial set determined by the custom properties
set in the style rule, and on modification I need to coerce the
provided key to a string, and then go mutate the style rule
accordingly.  When the style rule is mutated to add/remove custom
properties, I also need to mutate the exposed keys on the object.  (In
other words, this object has a bidirectional link with a style rule;
it just exposes a more convenient and specialized interface for custom
properties specifically.)

Right now I'm defining this via the WebIDL getter/setter/etc hooks,
which ends up defining an "object map".  This is bad practice, though,
because anything set on the prototype chain will show up as a
(non-own) key, potentially causing confusion.

I'd like to convert this over to an ES Map, as that avoids the above
issue and gets me all the Map extras for free, which is nice.
However, I don't think it's currently possible to do what I need.

Is it possible add appropriate hooks to the ES spec to let me define
the [[MapData]] via a spec, rather than as an initially-empty list of
tuples that get/set unconditionally read from?  I need to be able to
define in spec-ese that the [[MapData]] tuples consist of some list of
data from a style rule, and that whenever a value gets set, I first
coerce the key to a string, and then go mutate the style rule instead
of the [[MapData]] (it then picks up the mutated data by virtue of
being defined by the style rule).

(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.)

Alternately: Proxies?  Is that possible?  What benefits/drawbacks come
from that?

~TJ


More information about the es-discuss mailing list