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

Dmitry Soshnikov dmitry.soshnikov at gmail.com
Mon Oct 8 12:15:23 PDT 2012

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

> Dmitry Soshnikov wrote:
>> FWIW, we'd better stick with some reduced number of methods for
>> meta-traps.
>> As it turns out, we already have several different techniques which
>> solve nearly the same problems:
>> - Proxies,
>> - Object.observe
>> - Unstratified proposals like this one (which BTW, have been already
>> discussed many times; IIRC, the last time we were talking about
>> unstratified traps, it was said like "no one needs these Pythonish
>> __names__, we need proxies". Although, I don't see nothing too bad if
>> the traps will be defined directly on objects, especially if with some
>> @"private" semantics which cannot be just read as a simple property).
>> What I'm saying -- better not to create too many the same entities for
>> similar purposes. If we'll have some unstratified private hooks, I can
>> predict no one will need proxies or Object.observe.
> I still have the feeling proxies are too big bullet for this. I see the
> place of proxies in meta-programming pre se, simulating whole protocals,
> filling missing properties not envision before etc.
> To use a proxy to do such a natural thing as splitting [[Call]] and
> [[Construct]] seems to be a bit of misuse. For me.
> But if there is a "no __init__" movement there, ok. I just pointed to that
> fact of @iterator, and honestly I think @call and @construct are on the
> same level - enabling declaration of behaviour for basic, not-so-meta,
> language constructs (be it for-of or new/super).

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 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?

Other languages, BTW, like Ruby, allows separation of trapping allocation
and initialization steps. There classes' `new` method is just a wrapper
over `allocate` (ES's [[Construct]] and `initialize` (already user-level
constructor function code).

I could easily imaging things like this:

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.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121008/796a1ef0/attachment.html>

More information about the es-discuss mailing list