[[Call]] vs. [[Construct]] using symbols
herby at mailbox.sk
Tue Oct 9 00:28:13 PDT 2012
Dmitry Soshnikov wrote:
> What I thought though -- why do we need @call at all in this semantics?
> I'd rather disallowed calling classes at all at semantics level (aren't
> this only to cover this problem use-case with if (!(this instanceof
> Foo)) ?). If to reflect the behavior of embedded classes -- when you may
> call new Array(...) and just Array(), then I don't think so either. The
> only good use-case of calling native constructors as functions is the
> type conversion. To what exactly we want to convert the type when will
> call the class?
> So probably to disallowing calls at all (with even early errors) may
> look better.
> So -- what are good use cases for providing call(...) for user-defined
1. They are max-min classes. _Maximally_ minimal means it should
restrict semantics as least as possible, so it can be used as a
cornerstone for as much ways of future improvement as possible. @call
and @construct do not restrict the behaviour if all options are left.
2. As I posted a few posts before, sensible defaults should provide such
restriction if wished:
- if both @construct and @call are present, distinguish the behaviour
for new/super and plain call.
- if @call is present but @construct is not, let new/super reuse the
code of @call
- if @construct is present but @call is not, new/super should work but
plain call should throw.
More information about the es-discuss