On Thu, Sep 8, 2011 at 7:55 AM, Tom Van Cutsem <[email protected]> wrote:
> 2011/9/8 David Bruant <[email protected]> > >> ** >> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
