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

Herby Vojčík herby at mailbox.sk
Fri Oct 12 12:21:23 PDT 2012



Brendan Eich wrote:
> Thanks, Tom.
>
> At this point, without a TC39 exception, even with unique symbols, I
> think this is a strawman (so ES7 at earliest). Anyone willing to write
> it up?

As a generic callable objects proposal, yes.

But I am still saying there is a max-min proposal, which only puts this 
semantics into max-min classes. Where it, imho, has its value, and is 
easy to implement.

This could be part of ES6, wouldn't it? And it could be also the first 
step to full-blown callable objects, should they appear later.

Herby

> /be
>
> Tom Van Cutsem wrote:
>> 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 <mailto: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 <mailto:es-discuss at mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list