Should protocols be able to run per-instance initialization logic? (constructor side effects)

[LeaVerou]

This is somewhat related to #13, except #13 is about class-wide initialization logic, whereas this is about per-instance initialization logic.

In my experience implementing protocol-like patterns for years, it is exceedingly common to need to run some kind of initialization logic on each instance, and since constructors are immutable, it is currently impossible without consumer involvement.

Since constructor is not a valid member name anyway (#57), I wonder if protocols could support a special constructor() provided member that would allow them to run constructor initialization logic. This would run before the host class constructor logic, but after the superclass constructor.

In terms of prior art, it appears that this is possible in many languages that support traits/interfaces/partials, though far from all:

• Ruby mixins (via initialize)
• Python (via super())
• Dart: fields with initializers
• Scala traits

Do note that if we support class fields with initializers as provided members (see #49 (comment) ) then constructor side effects become possible, just a little annoying. Most of the languages that do not support constructor side effects on principle seem to also not support fields.

That said, if this were possible, one can add constructor side effects to literally any class, including built-ins, by creating and implementing a dummy protocol, and monitor every created instance which seems undesirable for a variety of reasons. So perhaps it should require some kind of double handshake, though ideally not O(N) on the number of protocols.

[ljharb]

It definitely should not be possible for something to be able to add a "constructor hook" of any kind. Public fields are just syntax sugar for lines of code inside the constructor, and nobody but the class author should be able to put code inside the constructor.

[Jamesernator]

This would run before the host class constructor logic, but after the superclass constructor.

For supporting mixins it'd be better if the class simply had control of when such constructors ran, for the imperative form it could just be a regular call in the constructor (this assumes some form of protocol fields, which without protocol constructors are far less useful):

// Suppose EventTarget were a mixin protocol instead

protocol EventTarget {
    // Part of EventTarget's implicit constructor()
    field #registeredListeners = new Map();

    constructor() {
        console.log("Installed field 1");
    }

    addEventListener(eventName, cb) {
        // ... add to #registeredListeners
    }
}


class Foo {
    constructor() {
        // Installs neccessary mixin fields, and calls EventTarget.constructor on this
        Protocol.implementInstance(this, EventTarget);
    }

    static {
        Protocol.implementPrototype(Foo, EventTarget);
    }
}

For a declarative form we could just have these be run in source order with fields:

class Foo {
     field1 = console.log("Installed field 1");
     // Performs Protocol.implementPrototype immediately and calls Protocol.implementInstance in
     // source order with field1 and field2
     implements EventTarget {}
     field2 = console.log("Installed field 2");
}

This does mean for a foo implements Foo to succeed we would require both Protocol.implementPrototype and Protocol.implementInstance to be successfully called (though the latter could be optional if the protocol is not mixin-like).

[LeaVerou]

@Jamesernator There is currently no concept of implementing a protocol on an instance. I suppose technically it could be done (depending on the specifics of the spec), but it's quite inefficient so it should not be the way to go for anything common.

It definitely should not be possible for something to be able to add a "constructor hook" of any kind. Public fields are just syntax sugar for lines of code inside the constructor, and nobody but the class author should be able to put code inside the constructor.

Then should we make it easier for the class author to consent?

• Standardize a convention so that triggering constructor side effects on a protocol is predictable?
• Make it easy to call that convention for multiple or all implemented protocols at once?

[Jamesernator]

There is currently no concept of implementing a protocol on an instance.

But that's the whole point of having per-instance initialization logic, that the protocol installs additional data (either via protocol-installed-fields if we support that, or via weakmaps). It would be rather strange if we allowed obj implements SomeProtocol to return true if the initializer had never run.

[ljharb]

A protocol can certainly be implemented on an instance, or on any object whatsoever - "thenables" for example.

[bakkot]

I think it's fine for this not to be standardized. Protocols that need it can provide an initialize method (either in the protocol or just somewhere else) which the class should call itself.

[LeaVerou]

Okay, it looks like we have consensus not to have this.