callable objects ?

Dean Landolt dean at deanlandolt.com
Tue Apr 17 18:20:09 PDT 2012


On Tue, Apr 17, 2012 at 7:06 PM, Brendan Eich <brendan at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120417/92bc223e/attachment-0001.html>


More information about the es-discuss mailing list