should we have a Symbol-based acquisition protocol

[michaelficarra]

I don't really like establishing new String-based protocols. Right now, the governor protocol is a pair of string-named methods ("acquire"/"asyncAcquire") which would most often be called internally within AsyncIterator.prototype and Governor.prototype methods. This really makes me think it's better to use symbols for this protocol. If we do use symbols, where should they live? And should we have a Governor.prototype.acquire that just defers to the symbol?

[bakkot]

I don't really like establishing new String-based protocols.

Why not?

I think it's a bad idea in two cases: when this is a protocol that arbitrary objects might implement (like Iterator), or when you want to switch on the presence of the protocol (like Promise). But neither holds here.

Note that the resolution of the subclassing discussion in Set methods - "consume the receiver by internal state, but arguments by their public interface" - essentially amounts to creating a protocol whenever consuming an object as an argument. I don't think this should imply that every object which is consumed as an argument needs to have a Symbol-named public interface. But that would be the consequence if we decide we want to avoid new String-based protocols.

[michaelficarra]

Why not?

I could turn this around and ask you why not symbols. If first-class protocols ever becomes a thing, it will encourage the definition of Symbol-based protocols unless Strings are requested. If we can, I would like Governor to look like something that would've been created by a first-class protocol.

I think it's a bad idea in two cases

I agree that it's clear-cut in those cases, but that doesn't imply it's clearly the opposite outside of those cases.

Note that the resolution of the subclassing discussion in Set methods - "consume the receiver by internal state, but arguments by their public interface" - essentially amounts to creating a protocol whenever consuming an object as an argument.

I think this is actually getting to the heart of it. For that decision, we were talking about an interface that was mostly designed for use by humans. In this case, we're talking about an interface that will, I believe, more often be called by built-in machinery than JavaScript developers. So that makes me think we should prefer the Symbol-based interface.

[bakkot]

I could turn this around and ask you why not symbols.

Because strings are easier to work with for developers. So they should be the default in the absence of an affirmative reason to use symbols, which I don't see here.