Defer `implemented by`?

[LeaVerou]

The current proposal defines an implemented by syntax for protocols to include implementations for certain existing classes:

protocol Foldable {
  // ...

  implemented by Array {
    foldr (f, memo) {
      // implementation elided
    }
  }
}

Is this MVP, given this can already be done via Protocol.implement()?

protocol Foldable {
  // ...
}

Array.prototype[Foldable.foldr] = function foldr (f, memo) {
  // implementation elided
};
Protocol.implement(Array, Foldable);

How common is the use case of implementing protocols on built-ins, inline? Is it worth having dedicated syntax sugar, this early?

[ljharb]

It seems pretty valuable to include a syntactic form, since that should be preferred over API forms when available, and since it's inside the scope of a protocol block the risk seems pretty negligible?

[LeaVerou]

It's not a question of value, but scope. The larger the API surface, the bigger the implementation cost and even small things require tests, docs etc. Also, the larger the API surface, the harder it can be to learn.

That said, if we need to have syntax that is decoupled from the class definition, it seems that it could make it much more broadly useful to move it outside the protocol definition too:

implement Foldable for Array {
	foldr (f, memo) {
      // implementation elided
    }
}

A similar idea was proposed in #34 by @iddan but without the symbol sugar.

[michaelficarra]

Yeah I'm fine dropping this and bringing it in a follow-up if we feel it'd be useful later.

[LeaVerou]

Yeah I'm fine dropping this and bringing it in a follow-up if we feel it'd be useful later.

Do you have any thoughts on moving it outside the protocol definition instead? ( #63 (comment) )

[michaelficarra]

I have these thoughts: #63 (comment)

[LeaVerou]

I have these thoughts: #63 (comment)

I think that might be the wrong link?

[michaelficarra]

Oops: #34 (comment)

(this was not my fault, a browser bug caused this and I can reproduce it!)

[LeaVerou]

The current approach encourages the developer to only define protocol implementations for either classes they own or protocols they own. Of course, everything can be circumvented by manually defining the required properties and calling Protocol.implement.

I do think it's a little strange to have implemented by as ONLY a declarative syntax with no constructor counterpart and Protocol.implement() as ONLY an imperative syntax with no declarative counterpart. Moving implemented by outside the protocol would address both issues. But I don't feel strongly about it.

[michaelficarra]

I do think it's a little strange to have implemented by as ONLY a declarative syntax with no constructor counterpart and Protocol.implement() as ONLY an imperative syntax with no declarative counterpart.

These are the same thing though? We have one declarative form available within the protocol definition, one declarative form available in class heads, and one imperative form: Protocol.implement. These are all each others' "counterparts" for requesting the protocol implementation. Changing where the first declarative option can be placed doesn't change that.

[LeaVerou]

We don't have a structured-yet-imperative form of the Function constructor, so there cannot be an imperative counterpart to class C implements P. But the imperative counterpart of implemented by would be a Protocol constructor option. Protocol.implement() is outside both the class definition and the protocol definition.