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

Herby Vojčík herby at mailbox.sk
Mon Oct 8 13:20:13 PDT 2012



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)`.

> 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


More information about the es-discuss mailing list