Function identity of non-configurable accessors

Allen Wirfs-Brock allen at
Tue Dec 18 11:24:30 PST 2012

On Dec 18, 2012, at 10:34 AM, Mark S. Miller wrote:

> On Tue, Dec 18, 2012 at 9:38 AM, Allen Wirfs-Brock
> <allen at> 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
> <> 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.

Similarly, then a value: identify (actually value)  stability invariant is also missing...

This diagram is based upon [[DefineOwnProperty]] for ordinary objects.  The fact it is specified as an internal method is a way of explicitly saying that exotic objects might apply different rules.  That has pretty much always been the ES definition of "host object", an object that doesn't follow the ordinary rules.

> 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).

I think you and I differ on what "useful static reasoning" means.  To me, wearing the hat of an application developer who is predominately dealing with my own or other trusted code, it means that I can reason about the expect behavior of my program using the ordinary semantics plus any exceptional semantics that I am explicitly expecting to deal with.  Anything else that might occur corresponds to a "bug".  I look for and test for bugs, but realistically I never expect a program to be totally bug free.

However, in your description above you use the term "safely" which I understand that for you goes hand-in-hand with "useful". For high integrity code, static reasoning is presumably only useful if it is also safe from an integrity perspective.  Basically, you need perfect code.  You can't tolerate bugs in your code, your reasoning, or violations of the invariants that are the axioms of you reasoning.

This seems like the crux of  matter WRT whether OCAP within a general purpose OO language can be useful as the sole high integrity encapsulation mechanism.  To you, as a builder of high integrity sandboxes, enforcement of certain invariants are essential.  To me, as a application programmer or even a library programmer, enforcement of these invariants are generally unnecessary. If enforcement impacts performance or expressibility they have a negative impact on my ability to get my job done.

I wrote about some related issues here:
Personally, I think we need the sort of kernel/framework separation I wrote about there.  OCAP probably isn't the sole answer.

> 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.

I buy this and I'm sure you've probably described a specific scenario already.  Can you provide a link to the specific exploit you have in mind here.


> --
>    Cheers,
>    --MarkM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list