Complete Minimal Classes

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Mon Apr 9 08:35:17 PDT 2012


I think separating [[Call]] and [[Construct]] to different bodies might be
a good idea. But to preserve flexibility, I also think that if you do

MyClass.call(Object.create(MyClass.prototype));

it should call the [[Construct]]. i.e. if it should use [[Construct]] when
'this' is an instance of the class (inherits from it's prototype).

I often call functions that are supposed to be constructors on completely
different objects that maybe inherit from that function or maybe not. This
would open up the door for making it up to the class whether it works
without the 'new' keyword, e.g.

class MyClass {
  construct (stuff, args...) {
    // Stuff
  },

  call () {
    return MyClass.apply(Object.create(MyClass.prototype), arguments);
  }
}

// Both do the same thing
new MyClass();
MyClass();

Cheers,
Jussi

On Mon, Apr 9, 2012 at 12:17 PM, Herby Vojčík <herby at mailbox.sk> wrote:

>
>
> Kevin Smith wrote:
>
>>    I always disliked that some functions in ECMAScript 5 can be invoked
>>    as either a function or a constructor. What would you want an entity
>>    Foo for that can be invoked in two ways? E.g.:
>>          new Foo(...)
>>          Foo(...)
>>
>
> My answer to this is probably a little lame and self-referencing, but
> "this is the JS model". It has its pros - minimal, simple, allows
> interesting composition of things. And of course it has cons.
> I'd not change it, but embrace it.
>
>
>  Maybe Brendan can answer that one?  : )
>>
>> Seriously, though, it's a fair question.  My first response is that
>> since the Chapter 15 "classes" exhibit this behavior, we should be able
>> to fully express it in a class syntax.
>>
>> But beyond that, how should we deal with this situation?  We could make
>> classes *not* implement [[Call]], but that would mean we'd have
>> functions that didn't implement [[Call]], which is (AFAIK) truly novel
>> and perhaps a little bizarre.  I don't see that happening, but I could
>> be wrong.
>>
>> So if [[Call]]/[[Construct]] duality is a fact, how *should* we deal
>> with it?
>>
>> 1)  Ignore the possibility of the constructor being [[Call]]ed.  This is
>> the typical response, because it's the easiest.  It's also the most
>> error-prone.
>>
>> 2)  Use a best-effort approximation to detect a [[Call]] as in:
>> https://github.com/joyent/**node/blob/master/lib/buffer.**js#L211-213<https://github.com/joyent/node/blob/master/lib/buffer.js#L211-213>
>>
>> 3) Separate the two behaviors into separate bodies, with a reasonable
>> default for the [[Call]] operation.
>>
>> I think (3) makes the most sense.  What do you think?
>>
>
> I am for (3), but there are three reasonable defaults imo:
>
> - call the [[Construct]] body as a function
> - do nothing
> - throw an early error
>
> and as I outlined, there probably should be ways to select from these
> default (e.g. static this / static undefined / static throw).
>
>  kevin
>>
>
> Herby
>
> ______________________________**_________________
> 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/20120409/9780d716/attachment-0001.html>


More information about the es-discuss mailing list