[[Call]] vs. [[Construct]] using symbols

Tom Van Cutsem tomvc.be at gmail.com
Mon Oct 8 12:19:07 PDT 2012


I think we've been over this before. See the April thread "callable
objects?"

Brendan at that point also proposed to use private names (we didn't then
have the distinction between private and unique symbols): <
https://mail.mozilla.org/pipermail/es-discuss/2012-April/022368.html>

I don't see any problem with this since the call and construct traps don't
have any invariant checks associated with them. And I agree it would be
weird if proxies were the only available tool to discern [[Call]] from
[[Construct]]. Brendan gave more good reasons here: <
https://mail.mozilla.org/pipermail/es-discuss/2012-April/022394.html>.

I think the important points w.r.t. invariants are:
- you can't override the built-in [[Call]] and [[Construct]] behavior of an
ECMAScript function object.
- the result of the typeof operator shouldn't depend on the
presence/absence of the @call/@construct unique symbols.

Cheers,
Tom

2012/10/6 Brendan Eich <brendan at mozilla.org>

> Before we add more unstratified traps, I'd like Tom and Mark to comment.
> They've thought a lot about invariants to preserve even with proxies in the
> picture, and also for non-proxies. And they have a use-case to test
> against: SES.
>
>
> Herby Vojčík wrote:
>
>> But this has some quirks to solve, like typeof must be "function" for
>> every object having @call, but what about object having only @construct?
>>
>
> If we do this, then let's hope testing (@construct in obj) isn't too bad.
> I suspect it won't be all that common.
>
> /be
>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121008/a0b54586/attachment.html>


More information about the es-discuss mailing list