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

Dmitry Soshnikov dmitry.soshnikov at gmail.com
Mon Oct 8 14:08:07 PDT 2012


On Mon, Oct 8, 2012 at 1:20 PM, Herby Vojčík <herby at mailbox.sk> wrote:

>
>
> Dmitry Soshnikov wrote:
>
>>
>>
>> On Mon, Oct 8, 2012 at 1:04 AM, Herby Vojčík <herby at mailbox.sk
>> <mailto:herby at mailbox.sk>> wrote:
>>
>>
>>
>>     Dmitry Soshnikov wrote:
>>
>> Notice though, that class's constructor(...) method (or @construct as
>> you propose) does not reflect [[Construct]]. The constructor method is
>> just the constructor function code itself. I.e. the only thing it does
>> is _initializes_ _already created_ instance. So we cannot control
>>
>
> What I propose is to use different code for [[Call]] and
> instance-initialization in [[Construct]]. Maybe I was mistaken in what
> [[Construct]] does, see below.
>
>
>  instance allocation in here, etc (this is what [[Construct]] does and
>> this is how it works in proxies).
>>
>> Although, I agree, if @iterator is on the objects/classes, then why not
>> other special traps?
>>
>
>
>  class Foo {
>>
>>    // meta-level hh
>>
>>    // just a wrapper
>>    @new(...args) {
>>      this. at allocate(...args);
>>      this. at constructor(...args);
>>    }
>>
>>    // aka [[Construct]]
>>    @allocate(...args) {
>>      // own allocation
>>    }
>>
>>    @construct(...args) {
>>      // user-level init
>>    }
>>
>>    @call(...args) {
>>      // simple call
>>    }
>>
>>    @iterator(...args) { ... }
>>
>>    // user-level methods
>>
>>   fromBar(bar) {
>>    // calls Foo. at new.call(this, bar);
>>    return new Foo(bar);
>>   }
>>
>> // ETC.
>>
>> }
>>
>
> This seems too complicated, very detailed granularity.
> I was in impression that
>   - allocation is done in new operator itself
>   - [[Construct]] is invoked inside new as well as in super
>   - [[Call]] is obvious.
>
> I may have mistaken this. No problem if it is called @init instead of
> @construct (maybe even introducing [[Init]] thereby making [[Construct]]
> and super running the same initialization code by referring to [[Init]]).
> What I wanted to achieve, is to separate [[Call]] from
> instance-initialization of new/super declaratively, and allow to replace
> the `if (!(this instanceof Foo))` method (which fails if I call it with
> already initialized Foo instance, anyway).
>
> Seems to me like a nice little clean. And in par with replacing
> `SuperFoo.apply(this, arguments)` with `super(...arguments)`.
>
>

The example above was just an example. Yes, in real ES semantics allocation
is done in the [[Construct]] which is called by `new`. Then [[Construct]]
already applies the function (via [[Call]]) in the context of the created
instance.

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.

PHP, e.g. has __construct(...) and __call(...). The former is our
constructor(...), but the later is not about class calling, but about
missed methods catching (aka __noSuchMethod__).

So -- what are good use cases for providing call(...) for user-defined
classes?

Dmitry



>
>  Though, that's said, then we'll have several the same semantically
>> entities (proxies, unstratified traps, Object.observe) with different
>> approaches. And it's better to reduce them. I like unstratified
>> @"private" hooks. Don't see the reason why should I use Proxy in this
>> case (and how? -- by proxying what? -- prototype property of the class
>> object manually? come on...)
>>
>> Dmitry
>>
>
> Herby
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121008/95bdf91b/attachment.html>


More information about the es-discuss mailing list