That's a good question. Currently I don't believe there is a way. I'm kind of leaning toward this suggestion from #45, which would make the ProtocolName.* properties the functions themselves but also usable as their own names. A little bit magic, but it's a really nice way to solve the problem.

For context, @ljharb’s idea was:

Alternatively Functor.map could be a function that Symbol.toPrimitives to the symbol :-p

My initial reaction was "I love this". It's so brilliantly clever and elegant.

Note

"A little bit magic" is not a problem in itself. Magic can improve UX tremendously when it predicts intent accurately most of the time, and provides a way out for the small % of cases when it doesn't (unless that's 0%). But because the UX of magic is worse than alternatives when it doesn't predict intent correctly, it's only an acceptable tradeoff when that happens very rarely. Most of the hate on "magic" is due to magic that either fails to predict intent correctly too often, or provides no way out when it doesn't.

But upon some reflection, I do have serious reservations.

We have no way to clone functions, so when implementing a protocol, its provided functions would be copied over with their Symbol.toPrimitive properties still attached. This means they would work differently than regular functions on the host classes too, and there would be no way to use protocols with functions that don't do that. For protocols to be widely adopted, we need them to be as close as possible to regular class members so authors can easily move things from one to the other.
It depends on the provided members being objects. There is no way to attach a Symbol.toPrimitive on primitive properties, or even accessors.

If we can't do that because it's too icky or implementers don't like it, yeah, I think we can put some object on the protocol to hold them. Importantly, the only name we could really stick that object on would be prototype (see #57) unless we also put all the required/provided names into their own object(s), which I'd really like to avoid.

I think prototype makes a lot of sense, but what about static members? If we follow similar patterns to classes, these would need to be added to the protocol itself, but ProtocolName.memberName is already a symbol.
Perhaps we could hang them on a constructor object instead of the protocol itself. Or, follow @ziadkh0’s idea:

I'm not advocating for it, but could Foo[Foo.bar] work? 😅

…but then, the prototype members would also need to use their symbols.

Though using symbols as the member names may be a good idea anyway since technically foo and ["foo"] are distinct provided members and can co-exist (I opened #59 so we can get a resolution on this).

Another thing to consider is that once we have these objects, they need to be live, which means protocols can be extended post-hoc.

How to access provided member implementations? #55

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions