Mark S. Miller
erights at google.com
Tue Sep 6 08:53:29 PDT 2011
On Tue, Sep 6, 2011 at 7:35 AM, David Bruant <david.bruant at labri.fr> wrote:
> I guess i should ask the question more directly:
> Should (some) current inheritance-based expectations be turn into
> invariants? Are there good arguments to do so? Or are own layer invariants
> In a way, having a non-trappable (and thus reliable) Object.getPrototypeOf
> and reliable non-configurable properties and non-extensibility invariants
> could be enough, but it's worth asking (adding Mark in cc).
Hi David, thanks for your vigilance!
I think the following set are enough:
a) reliable own invariants
b) reliable and non-trapping Object.getPrototypeOf
c) non-mutation of the prototype chain.
This still provides a simple and learnable model of what is and is not
guaranteed to be reliable. To get reliable non-own information, ascend the
prototype chain manually.
It is problematic that #c is currently only guaranteed for non-extensible
objects. I would prefer prohibiting mutation of the prototype chain for all
objects. Is there any way we could get agreement on that for ES6?
As a contrary example, Mike Stay (cc'ed) is checking emulated extensibility
within his proxy emulation in ES5/3 (Caja's ES5 to ES3 translator and
runtime) to avoid a problematic case, relying on the following invariant:
* If all the objects on the prototype chain above obj are non-extensible,
and I enumerate all their properties now to mask them on obj undeletably,
then afterwards a [[Get]] on obj will never obtain a value provided by obj's
Obviously, we will not try to run ES5/3 on an ES6 system, so it does not
matter that actual proxies invalidate this particular bit of code. But it
does illustrate how easy it is to bake into code assumptions of indirect
invariants which are guaranteed in earlier versions of JS.
Nevertheless, having noted this contrary example for the record (and my
possible future shame ;)), I still think the above set of three weaker
invariants represents a good compromise.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss