On Tue, Dec 18, 2012 at 9:38 AM, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote: > > The whole whole idea of such invariants was a late addition to ES5, and not > without some controversy. I don't think anyone believed that ES5 had a > complete set of invariants or even what that might be.
As part of the proxy work, Tom and I have started a more complete list of invariants. Yes, it would be good to make more progress on this. > > Regarding the identify of stored/retrieved get/set functions, for "ordinary > objects" that is fairly explicit in the ES5 spec. [[DefineOwnProperty]] sets > a properties internal attributes to the provided values and > [[GetOwnProperty]] retrieves the values of those attributes. The only > specified way to modify the identify of such a stored get/set attribute would > be by an intervening [[DefineOwnProperty]] call. Hence, we have identify > preservation across setting/retrieving of get/set accessor functions. I've > thought about making this even more explicit, but the ES5 language seems > clear enough. Agreed so far. > > For "exotic objects", as is usual for most such hypothetical invariants, > anything goes in ES5. So, a host object could change the identity of a > get/set accessor function. That doesn't bother me, "exotic objects" are an > escape mechanism for unanticipated new semantics. But, the provider of such > an object really needs to fully document its behavior. Otherwise, its not > going to be very useful. But if the documentation says that the identify of > get/set functions are not preserved, then that seems like sufficient warning. This seems nonsensical to me. At <http://wiki.ecmascript.org/doku.php?id=es3.1:attribute_states> is my summary of the point of some of these invariants -- that no state transitions beyond those shown in this diagram are possible. When David pointed out the getter/setter identity stability invariant was missing, this surprised me. It is clearly an oversight. It never occurred to me when drawing this diagram that the lack of getter/setter change applies only to ordinary objects. JavaScript is a very dynamically typed language. Static reasoning proceeds safely often without knowledge of the object types of the values involved, nor (as usual) of potential aliasing. These invariants enable useful static reasoning precisely because they are universal (and so not type dependent) and monotonic (and so aliasing independent). Further, as I've mentioned several times, direct proxies can leverage the presence of a single invariant-violating exotic object to create any number of other invariant violating objects. -- Cheers, --MarkM _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
