Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More examples and motivations #17

Open
samuelgoto opened this issue Sep 26, 2017 · 3 comments
Open

More examples and motivations #17

samuelgoto opened this issue Sep 26, 2017 · 3 comments

Comments

@samuelgoto
Copy link

I'm still struggling what problems this solves, can you help me enumerating some of the most compelling use cases this enables? You mentioned iter-ables/then-ables but this being a userland affordance, what are the most promising things you think this will enable? Is there an application for constructing/manipulating the DOM? Is there an application for collections? What are the most compelling problems this is addressing? And for each example, articulate clearly how this proposal helps (as opposed to without it)?

@chriskrycho
Copy link

As merely an interested observer, I can say that it has two really helpful use cases (which I could write up more formally and submit a PR if someone wants):

  1. It is is quite useful for being able to easily implement common behavior across variants of a base type, without using inheritance. For example, I've been playing with building a (fairly standard) Maybe and Result type library here, and if you look at the class definitions, you'll see that they're literally identical for the most part. The proposed approach would allow these kinds of common behavior to live on the underlying protocol definition, with only the bits that vary implemented separately. In my experience with Rust, this is a lot less fragile than traditional inheritance schemes as a way of solving this problem!

  2. Being able to apply an interface to an existing item after its creation is extremely helpful for abstracting common behavior across different types. For example, Ramda and lodash have to do quite a bit of hoop-jumping to be able to map across objects, arrays, sets, etc. The Functor example supplied would make it straightforward for them to simply use that protocol to define and inherently apply the map operation to any and all types, without either doing the nasty prototype chaining or, in many cases, needing to rewrite the behavior repeatedly, since a default implementation could lean on other protocols (i.e. iteration) to do its work.

@bmeck
Copy link
Member

bmeck commented Sep 29, 2017

It also helps remove problems like the ones in https://twitter.com/jasnell/status/913794961958510592 where a string based interface system was poisoning the ecosystem.

@mlanza
Copy link

mlanza commented May 5, 2023

What problems does having protocols solve? I'm not sure I understand the question.

Clojure uses them. I wanted them so badly in JavaScript that I implemented them, for all the same reasons Clojure did, and have been using them happily for going on a decade.

I'd be thrilled if this made it into JavaScript proper where it could be implemented for performance.

The most compelling use cases Clojure describes. It allows you to use the same set of functions for manipulating data structures without always caring about the precise data structure you're dealing with. That is, the decisions about performance and behavior for something are made at an earlier point of execution, and later the program performs its routine work using canned functions and not caring about concrete types, only abstractions. Having been using them for years, it's been a real boon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants