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

Rick Waldron waldron.rick at gmail.com
Sun Oct 7 08:21:42 PDT 2012


On Sun, Oct 7, 2012 at 5:10 AM, Herby Vojčík <herby at mailbox.sk> wrote:

>
>
> Brendan Eich wrote:
>
>> 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.
>>
>
> These were just "extended" thoughs.
>
> The main thing I wanted to propose / get feedback is the simple [[Call]]
> vs [[Construct]] separation for max-min classes using const systemwide
> symbols @call and @construct, since we already have the precedent of
> @iterator (the rest were thoughts about possibility of generalizing it).
>
> In other words, no real traps at all. Just convenient names @construct
> and/or @call used instead of (also convenient) name 'constructor'.
>
> Like in:
>         class Foo {
>                 @construct(x, y) {
>                         // initialize the instance
>                 }
>                 @call(obj) {
>                         // convert obj into Foo
>                 }
>                 // the rest of the methods
>         }
> with the result of Foo constuctor function implemented so it can
> distingiush between [[Call]] and [[Construct]] context and doing the
> respective code.


I actually really like this idea.

It addresses a common pattern today, that looks like:

function Led( opts ) {
  if ( !(this instanceof Led) ) {
    return new Led( opts );
  }

  // ...
}

And it also fits a number of use cases of the spec itself, for built-ins:

call, contruct, object, spec section link

15.2.1, 15.2.2, Object
http://ecma-international.org/ecma-262/5.1/#sec-15.2.1
15.3.1, 15.3.2, Function
http://ecma-international.org/ecma-262/5.1/#sec-15.3.1
15.4.1, 15.4.2, Array
http://ecma-international.org/ecma-262/5.1/#sec-15.4.1
15.5.1, 15.5.2, String
http://ecma-international.org/ecma-262/5.1/#sec-15.5.1
15.6.1, 15.6.2, Boolean
http://ecma-international.org/ecma-262/5.1/#sec-15.6.1
15.7.1, 15.7.2, Number
http://ecma-international.org/ecma-262/5.1/#sec-15.7.1


Rick












>
>
> Herby
>
>
>  /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/20121007/4ce3b9f2/attachment.html>


More information about the es-discuss mailing list