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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
