Questions and concerns

[hatashiro]

First, thank you for publishing the proposal. I think it's quite interesting language feature. I generally like to design code with protocols, e.g. type class in Haskell or trait in Rust. However, I'm concerned that it works well in JS too.

I would like to make it clear that I am not a PLT expert and this is my first time to comment on language proposal. I may miss something or be completely wrong, and please feel free to correct me.

Working with dynamically typed language

I wonder if protocol works well in dynamically typed language. I understand there are module and mixin in Ruby, but I guess it is more like dynamic property/method injection. In JS, it can be easily done by providing a function to merge prototypes, or even just assign instance properties. Many major user-level libraries are already doing this, and it seems quite enough.

Also, because type cannot be checked statically in JS, dynamic type checks should be performed for protocols. However, I think checking protocols with implements can be redundant. For example, let me suggest an example of Promise implementing Monad.

class Promise implements Monad {
  [Monad.bind](f) {
    return this.then((x) => {
      const result = f(x);

      // here we may like to check if the result is properly Promise itself,
      // for `bind :: Monad m => m a -> (a -> m b) -> m b`

      // 1
      result implements Monad // this is wrong, because
                              // it shouldn't handle *any* Monad instance

      // 2
      result instanceof Promise // this is what we already have

      // 3
      typeof result[Monad.bind] === 'function' // I also think this is enough,
                                               // easy and no naming collision as well

      ...
    });
  }
}

For 3 above, we can simply do the same without protocols, and actually it's similar to what fantasy-land is doing now. I guess it can be done in user level and doing so seems completely natural.

The Monad example can be somewhat too much. However, I cannot come up with cases where protocols do something better than dynamic type checking with instanceof or typeof. I wonder if it is useful when a type and its protocol cannot be ensured statically.

First-class citizenship and dynamic implementation

Also, I have a concern of its first-class citizenship and dynamic implementation. Is there an example they work well together in dynamically typed language? I understand it's handy to extend native objects' functionality. Swift do somewhat similar thing with extension, but it's static and users can be helped by type system and IDE support. However, extending original objects dynamically can easily result in inability to read and track code. Protocols are even first class, so the extensions can be done with a protocol returned by other functions or got as arguments.

someAsyncFnExtendingXAndReturningProtocol(X, protocol => {
  Protocol.implement(X, protocol);
});

Surely the code above is silly. However, I doubt adding protocols pay off efforts not to write these kind of silly code. I think it should provide some kind of assurance and safety to users because it's where protocol becomes meaningful, such as not allowing non-root-level implementation.

Design with protocols

I love design with protocols (or type class in Haskell). It is common practice in Haskell to define proper type-class instances for a new type, and I believe it makes Haskell programmers not to care of repeating patterns, but to focus on important things. People familiar with Haskell type class or Scala/Rust trait may welcome protocols in JS, but I doubt most of JS developers, specifically entry-level people, can (or are willing to) be familiar with it. Learning new feature (or in this case I would call it a new way to write code) is usually pricy than experts think it is.

Conclusion

Ended up with a long post, but this is nothing but my personal concern, maybe from my ignorance. My concern may disappear when hearing and investigating more, so I would be happy to hear your opinion!

[keithamus]

but I doubt most of JS developers, specifically entry-level people, can (or are willing to) be familiar with it

I'll make a small point around this. Let's look at other language features as a counterpoint here - specifically Proxies. To ape your words (no intended snark though): People familiar with metaprogramming and using similar trap mechanisms in other languages may welcome Proxies in JS, but I doubt most of JS developers, specifically entry-level people, can (or are willing to) be familiar with it.

I don't think protocols (just like proxies) will be an application-code level feature (that is, writing code day-to-day where you're largely interfacing with libraries; jQuery, React and the likes). Protocols will serve to drive useful ergonomics in a first-class way, for all of these libraries - fantasy land included. React for example currently has sentinel properties to define things as "react elements" (React.createElement retuns an object with .$$typeof == Symbol(react.element)) that could be done in a first-class way with protocols, jQuery's own internal API could be protocol driven (see the amusing debate of: jQuery is a monad) but still have user friendly prototype methods.

In a more long-term game, I (personally - I am not the author) see protocols as a way to solve problems inherent to our dynamic duck-typing ways. See the problems around then becoming a half-way reserved method. It would be nice if we don't repeat those mistakes in the future - and Protocols seems to be an ideal way around that.