[Harmony Proxies] Proposal: Property fixing
Mark S. Miller
erights at google.com
Thu May 12 19:10:22 PDT 2011
On Thu, May 12, 2011 at 6:48 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
> Thanks Tom,
>
> As you point out, the are plenty of other implicit invariants that proxies
> don't enforce. For example:
> - a configurable property can be deleted
>
In ES5, cannot a conforming host object already break this invariant?
> - a [[Put]] to a non-writable data property does not change the value
> observable via [[Get]]
>
By the classification of the message I just sent, whether the property is a
non-writable data property at the time of [[Put]] is
Momentary.
> - the attributes of a configurable property can be changed
>
Conforming host objects can already violate this.
> - obj.hasOwnProperty("foo")===obj.hasOwnProperty("foo") //is true
>
Momentary.
> -Object.getOwnPropertyDescriptor(obj,"foo").hasOwnProperty("value) ) &&
> obj.foo===obj.foo //is true, ignoring NaN case
> or lots of other consistency invariants among sequences of traps
>
Momentary.
>
> I also wanted to point out that no modern browser fully respects the
> configurable invariants. Every browser implements RegExp.prototype.compile
> and the de-facto standard for its behavior blatantly modifies the
> properties specified in 15.10.7 which are defined to be configurable false
> and writable: false. The discussions that have occurred concerning this
> method concluded that it (with that behavior) is essential to the web and
> that it should be included in the next ES edition. I haven't figured out
> how we will reconcile this. Probably by turning the affected properties
> into accessors.
>
Fortunately, RegExp.prototype.compile is deletable on all major browsers. (I
know because initSES.js deletes it.)
>
>
> On May 12, 2011, at 5:40 AM, Tom Van Cutsem wrote:
>
> ...
>
>
> Most of the enforced properties have to do with classification: instanceof,
> typeof and === are operators used to classify objects, and classifications
> typically come with some implied invariants (I'm aware of the fact that
> instanceof tests can be non-monotonic in JS).
>
> For {freeze|seal|preventExtensions}, one can make the case that defensive
> programming is one of their main use cases. Allowing proxies to gratuitously
> break them feels like taking away a lot of the usefulness of these
> primitives.
>
>
> Generally, ES is not a hand holding language. In particular, I don't see
> why these invariants are more important to enforce than some of those I
> mention above. A buggy implementation can violate these invariants (and as
> I mentioned above, all browser implementations are to some degree buggy). A
> buggy library can forget to freeze even though it is spec'ed do so. I don't
> see why a buggy proxy is any more of a problem.
>
> My understanding was that a major motivation for these operations was to
> create objects that can be passed to untrusted code while being safe from
> tampering. The work around in the presences of proxies would seem to be
> don't pass any such buggy proxies or to create your own trusted proxy that
> wrappers the potentially buggy proxy.
>
> The use case is not always defensive programming, e.g. frozen objects
> facilitate caching without cache invalidation.
>
>
>
> You can presumably still do that cache based upon the implied invariant. A
> failure to respect the invariant within the proxy is a bug that you might
> want to have a test case for but probably shouldn't cause you to change your
> design. Just like most of the other object invariants that proxies don't
> guarantee but your program probably depends upon.
>
>
> W.r.t. non-configurable properties: at this point I am convinced that
> Sean's API is better than the current design of outright rejecting
> non-configurable properties. Surely there will be cases where proxies will
> need to emulate non-configurable properties. Also, the fact that the default
> forwarding handler can't straightforwardly delegate getOwnPropertyDescriptor
> calls to its target (since it has to change the property's configurability)
> is a bad smell.
>
>
> I don't like Sean's API because it requires the trapping infrastructure to
> build and perform validation against a potentially large data structure (per
> object table of all property names that have been set non-confgurable).
> That's the sort of complex invariant maintenance that I don't think belongs
> at the implementation level of a dynamic language. Consider as a use case
> the ES5 String object. String objects have a "virtual" property foe each
> character of their underlying string value. Each of these character
> properties is non-configurable but the String object itself is extensible.
> A string value potentially has millions of such character properties and
> they routinely have thousands of them. Using Proxies to implement this
> style of virtual properties over some fixed data source seems like a great
> use case. It should be possible and it should burden the underlying runtime
> with the overhead of validating a complex invariant that is practice would
> likely only fail during debugging of the Proxy.
>
>
> Building on an earlier idea proposed by David ("inheritance-safe proxies"),
> a compromise could be as follows:
> - allow proxies to emulate/intercept non-configurable properties without
> checking
> - introduce an "ESObject" abstraction such that if h is a user-defined
> proxy handler, ESObject(h) creates a "safe" proxy handler that checks
> conformance of the handler w.r.t. the above ES5 Object semantics. This can
> be useful for catching bugs, or preventing misbehavior, depending on your
> POV.
>
>
> This seems like a reasonable approach.
>
> I've come to view the "native object" semantics defined in ES5 section 8 as
> simply one of many possible object semantics that can be supported by the
> core ES language constructs. Most of the ES built-in object types implement
> some sort of dialect of the "native object" semantics. DOM objects have
> even greater divergence and arbitrary host objects in some implementation
> can diverge from "native object" semantics in even more ways. I thing
> Proxies needed to be view as being closer in power to host objects then they
> are to "native objects". Given this, it would be great to have a ESObject
> implementation that programmer can refine for the situations where they
> intend to make not or only minor variations form the standard semantics.
>
> In terms to the core semantics of Proxies, I think we should restrict
> ourselves to the semantics that are required to support the individual
> statements and operators of the core ES language. These are the same
> semantics that are needed to make those statements and operators operate the
> current range of native, built-in, host objects.
>
>
> Allen
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
Cheers,
--MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110512/1cef71f5/attachment.html>
More information about the es-discuss
mailing list