Good-bye constructor functions?

Herby Vojčík herby at
Tue Jan 8 00:54:44 PST 2013

Kevin Smith wrote:
> I think it's arguable either way.  I mean, the initializer-only behavior
> advocated by Allen et al makes the class useless when called (as opposed
> to new'd).
> I don't think such an opinionated approach is really necessary.  One can
> account for the funky behavior of the built-ins by providing an
> additional "call" hook on the class, and leave everything else as is.
>   When the class is called (as opposed to new'd), it would use that hook
> instead of the constructor.  ("super()" would still use the parent's
> constructor function.)
> It could be supported with syntax like so:
>      class C {
>          static(...args) { /* call behavior */ }
>      }

Read my reply to Allen, it shows more general solution there. In a few 
words, with class and constructor separated, you can specify what object 
should represent the class (and is given appropriate .prototype and 
[[Construct]]), would you want to (otherwise, plain object is created 
for you). One of the options is you can specify that a function should 
represent it:

   class C {
     static function(...args) { /* call behaviour */ };

though you can of course put any expression there. Another good 
candudate is {...} object literal.

> I think one could also make a case that the default behavior for such a
> hook would be to "new" the class, as some built-ins do (and as many
> current JS "classes" attempt to do):
>      class C {
>          static(...args) { return new C(...args); }
>      }

Yeah, in my proposal there is no default [[Call]] (have no reason for 
general object). But it is more general.

> This seems like a pretty clean design to me.
> { Kevin }


More information about the es-discuss mailing list