[[Call]] vs. [[Construct]] using symbols

Herby Vojčík 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
> classes?

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.

> Dmitry


More information about the es-discuss mailing list