[[Extensible]]and Proxies (Was: Proxy.isProxy )
allen at wirfs-brock.com
Thu Jul 14 21:27:35 PDT 2011
On Jul 14, 2011, at 4:59 PM, Mark S. Miller wrote:
> On Thu, Jul 14, 2011 at 3:00 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> On Jul 14, 2011, at 1:19 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.
Prior to ES5, [[Extensible]] did exist. We added it in a manner that was consistent for native objects. We may have over-stepped in requiring that host objects have such an internal property when in the past they didn't. I don't think there is any fundamental necessity that such an internal property exists for host objects or that it is possible to be able to place a host object into a state where properties cannot be added. I not sure that DOMs violate this, but I'm also not sure that they don't.
If an object (whether native or host) has such a state, then it clearly is a bug if new properties can be added when the object is in such a state. But is it a critical safely bug that must be proactively detected and prevented? I not yet convinced that it is or that the benefit of proactively guaranteeing that such an invariant cannot be violated is worth the cost.
>> and the host object invariants are incomplete and hard to make impossible to violated.
>> Host objects are part of the platform. A platform provider is free to violate any part of the spec they like, and there's nothing we can do about it other than to add tests to std test suites to make the violations obvious to the community.
> We could provide a defined interface mechanism that validates constraints or limits behavior in a way that guarantees the desired invariants. That's what Proxies appear to be trying to do, why not do it for host objects. If you can depend upon host objects actually supporting your invariants why does not matter whether or not Proxy objects also do so.
> I think this is key to the whole discussion, as you and I have discussed verbally. The main use case you seem to be thinking in terms of is Mozilla's own use, as a platform provider, of the proxy mechanism as a way to replace your current mechanisms for providing host objects. This is a laudable goal which I fully support. However, for your use as a platform provider, it is legitimate for you to provide yourself dangerous shortcuts that we cannot expose to untrusted code, given that you take responsibility for not abusing these dangerous shortcuts.
No, that is just one use case. However, in general I think the ability to use intercession to produce interesting object semantics is a valuable feature that has various uses include hosting other languages. However, I am content to leave the maintenance of complex invariants up to the implementors of such object semantics and to tolerate any failure to do so as user bugs alongs as they can't violate memory safety.
> For clarity, let's take an extreme example: peek and poke. For those who missed the history, peek and poke <http://en.wikipedia.org/wiki/PEEK_and_POKE> were primitives in some Basics for providing direct unchecked access to raw memory. If you, as platform providers, wanted to provide yourself with peek and poke operations in order to gain some efficiency or whatever, there's nothing fundamentally wrong with that. But clearly, no matter what the gains, that shortcut should never be exposed to untrusted code.
We aren't talking about implementation private extensions and we aren't talking about peek and poke which which can be used to violate fundamental memory safety invariants in any program. I don't see the issues we are talking about as involving invariants of such universal significance or which are exploitable in the same broad manner. If there are equivalent severity exploits that you are concerned about I haven't heard what there are yet.
> This also demonstrates out why the notorious Chapter 16 exemptions need to be tightened. As currently written, a platform could provide peek and poke as native methods without violating the spec. However, so far I am at a loss on how to tighten this up so that it is neither too tight for agreement nor too loose for safety. Perhaps this is the real 4.3.28 issue you were raising above?
I would be quite open to specifying memory safely invariants. I'm don't think there are many others of equal significance. Chapter 16 needs to be very loose or it would prevent most future extensions to the language.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss