On Tue, Apr 17, 2012 at 7:06 PM, Brendan Eich <bren...@mozilla.org> wrote:
> Axel Rauschmayer wrote: > >> I would add: [[HasInstance]] -> @hasInstance >> > > Yes, that one goes with @construct, and it seems safe to hook at > base-level because only instanceof uses [[HasInstance]]. > > As Mark and Tom argued in the Proxy design docs, stratifying in a new > proxy object is much safer when the trap is called all over, internally, > and at points in ECMA-262 and real VMs where "usercode" is not expected to > nest. > > Further-base level traps need to be considered carefully on a case-by-case > basis. This is really nice to see! For a while now I've figured the separate namespace that name objects offer could be a really useful, simplifying force... Now to try and stretch this a bit further: I wonder if __proto__ shouldn't be stratified with a @prototypeOf name -- read-only, of course, except during instantiation. We ought to be able to write to the @prototypeOf name in a @construct function, right? Thus, if we could overwrite @construct on functions this could subsume <| (or |> -- I can never remember which direction that's supposed to point :P)... Of course if we were to go this far why not take it one more step and offer up a @constructor name that's invariably linked to the @construct function responsible for creating an instance? And finally, we may as well go all out and also stratify the prototype property with a @prototype name. This last one's not an immediate win (but seems like the right thing long term), but the others solve real problems in a way consistent with the @call and @construct approach above. I couldn't speak to whether it's safe to override a function's @construct but if it turns out to be, what do people think of this?
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
