Proxying Native Objects: Use case
francois.remy.dev at outlook.com
Thu Jan 31 09:34:14 PST 2013
> >> I think such a getter notation exists in WebIDL to formalize scars from
> >> the past (like HTMLCollection) rather than to be used in new APIs
> > Yes and no. For exemple, something alike is envisionned to support custom properties in CSS. Something like:
> > element.style.myCustomProperty = true;
> > // set the my-custom-property custom CSS property
> How is this not future-hostile?
Custom properties are guarenteed to start with a prefix (EWCG sports 'my' and Tab sports 'var' but in concept this is identical) so that the getter only get in the way if the property name starts by that prefix. That prefix being secured for author additions only, it's impossible that any conflict will happen in the future.
> Do you have a link to where people are discussing this?
Feel free to comment on www-style, but if you want Tab's editor draft, it's here:
The most natural way seems to be to first, set up a getter behavior on the interface that deals with variable properties, and second, set up a vars map that exposes the variable properties that aren't set to their initial value.
FWIW, I support both additions, given the author prefix.
> Turning any object into a proxy is a no-go, because it means that things
> are aren't observed suddenly have to be observed and that anyone can
> insert arbitrary code in the middle of any operation on any object. It's
> pretty bad both for security and probably for performance too.
Yet you can already freeze an object in the middle of any operation. But I agree turning an object into a proxy is a bit more complex.
Would it be acceptable to instead just add an equivalent to __getNoSuchThing__ and __setNoSuchThing__ to native objects? It would, in fact, solve most of the envisioned use cases and is maybe more lightweight from an implementation point of view.
> I think having dispatchEvent accepting proxies is the easiest thing to
> do in your case.
The problem is that in the case of polyfilling you can't be sure the browser will think about proxy usage when they first implement the API then you're out of luck.
> If creating proxies for exotic objects become a real thing, maybe each
> exotic type can define its own reduced version of proxies like:
> document.createProxiedElement('string', proxiedElementHandler)
> The power proxiedElementHandler could be arbitrarily reduced by the spec
> of createProxiedElement. It could allow creating reduced "proxies" that
> can be inserted in the DOM without providing full abusive power than
> have the bad consequences for selector matching. It's possible in
> theory. In practice, I don't believe it'll happen :-s
That would satisfy even more objectives but as you said it put a lot of burden on the implementor side, not sure it's gonna happen anytime soon. But that's an approach worth pursuing in the long term if some cases really have to rely on it.
More information about the es-discuss