Complete Minimal Classes

Herby Vojčík herby at mailbox.sk
Mon Apr 9 02:17:52 PDT 2012



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
>
> 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


More information about the es-discuss mailing list