[+stay] On Tue, Sep 6, 2011 at 7:35 AM, David Bruant <david.bru...@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 > enough? > 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 at < http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/es53.js#5067> 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 prototype chain. 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. -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
