[Harmony Proxies] Non-extensible, sealed and frozen Proxies

[Mark S. Miller]

On Thu, Sep 8, 2011 at 7:55 AM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:

> 2011/9/8 David Bruant <david.bruant at labri.fr>
>
>> **
>> So the third argument would be the object the proxy would become.
>>
> [...]

> Otherwise, we violate the stability of ===. [...]
>


I am not proposing anything like a Smalltalk become.

But first, to avoid confusing, we need consistent terminology for the two
present roles for [[Class]].

1) What Object.prototype.toString.call() prints between "[object " and "]".

2) An internal nominal type, associated with a set of fixed internal methods
and possibly mutable internal state variables. The nominal type's integrity
relies on invariants maintained on these internal state variables. These
invariants are maintained both by these internal methods and by built in
functions, like Date.prototype.setFullYear(), that first check this nominal
type before mutating the object.


To elaborate on the proposal I'm making here,

a) The proxy does not actually become the fixedProps object. Rather, it
would treat Object.getPropertyDescriptors(fixedProps) as it now treats the
property descriptor map returned by fix().

b) From birth, the proxy has the same Object.prototype.toString.call()
behavior as fixedProps.

c) From birth, the proxy has the same nominal type, internal methods as
fixedProps. Also, internal mutable state properties should somehow be
shared, since these internal mutable state properties are part of the
invariants assumed by the internal methods and those built-ins
internal-state-accessing built-ins like Date.prototype.setFullYear().

The state sharing implied by #c is unfortunate, and could be avoided in
practice if we can find a variant of this proposal that ensures fixedProps
is indeed fresh. I don't have any clever ideas of how to do that.


What the proxy doesn't get from the fixedProps:

d) The fixedProps' identity.

e) The fixedProps' [[Prototype]]

f) The fixedProps' [[Construct]] method if a construct trap is provided to a
function proxy.

In enumerating these, I omitted the [[Call]] trap, realizing that we already
treat the callTrap in many ways similarly to how we propose here to treat
the fixedProps, for example, in the behavior of
Function.prototype.toString.call(). Were we to adopt this proposal, we
should probably promote the callTrap into having this role.


Were this proposal to be adopted,

    Date.prototype.setFullYear.call(Proxy.create(someFunnyObject, handler,
new Date()), 1957)

should work. It is perhaps unsatisfying that it would work without trapping
to the handler.


I don't know if I'm serious about any of this. It seems complicated and I'm
not sure how much payoff there is. But it does seem to be a principled
answer to many of the conundrums arising in this thread.



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110908/6a9e14d5/attachment.html>