[[Extensible]]and Proxies (Was: Proxy.isProxy )

Brendan Eich brendan at mozilla.com
Thu Jul 14 18:01:49 PDT 2011


On Jul 14, 2011, at 4:59 PM, Mark S. Miller wrote:

> Do you really think it makes sense to allow new properties to appear on non-extensible objects? Really?
> 
> Perhaps you do. Again, unless and until we get agreement to clean up these (irregularities, inconsistencies, features, whatever you want to call them) in 8.6.2, ES5.1 is, as you say, what it is. I hope we can do better.

Mark, hope you don't mind me jumping in -- I think I see a misunderstanding. Allen is not saying you should be able to extend non-extensible objects.

He is, I believe, noting how adding one or two ad-hoc restrictions on host objects, while leaving a large (or indefinite) list of other aspects of host objects free of such restrictions, is not good for the spec or its consumers.


> So we disagree WRT whether the specified behavior of features in current specification can be extrapolated as imposing limitation on future unrelated features and specifications. 
> 
> I agree that this is a good summary of our disagreement, yes.

I'm not sure -- it leaves open the question of whether we should do the work to fill all the gaps, so no unwarranted extrapolation is required. I think we may agree on one of (1) no restrictions on a few host object aspects; (2) a great many restrictions, so as to reliably enforce the desired invariants.

This assumes we can specify and  agree on the invariants.

I don't think anyone has written down those invariants in a way TC39 could evaluate and agree to put in the spec. It seems premature to conclude that we could not agree on the right set.

There will be some fine line-drawing. We can't just intercede everywhere without making proxies so powerful that you can't cheaply maintain certain security invariants. There's a tension between the "reflect everything and allow intercession in all operations" line advocated by David Ungar in a question to Tom at DLS last fall (about why Proxies do not intercede for === -- "did you chicken out?") and sandboxing the base and meta levels, providing a restricted subset of the language with strictly fewer meta operations.

My hope is that with modules and loaders, we can provide all the power Allen wants at the meta layer, in a way that does not break abstractions, and secure subsets can cheaply remove such capabilities.

But I admit to having mixed feelings about, e.g. Proxy.isProxy. If it's present in browsers without a subset opt-in, the web developers may start to call it on DOM NodeLists to detect whether they are running on a Firefox 7 or later that uses Proxies to implement NodeLists. That would be bad.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110714/e0a12e8a/attachment.html>


More information about the es-discuss mailing list