do release/asyncRelease pay for themselves?

[michaelficarra]

On one hand, it's nicer to write token.release() or token.asyncRelease() than token[Symbol.dispose]() or token[Symbol.asyncDispose](). On the other hand, it makes it more annoying to produce a GovernorToken. You either have to install each method under two different names or you have to inherit from some GovernToken.prototype which would have helpers that call the other one. This just doesn't seem worth it for the slight convenience, especially when much of the usage of governors will be through the using syntax or through other helpers like those on AsyncIterator.prototype or Governor.prototype, which means most people will never even hold a token, let alone manually release it. I think we should remove them.

[bakkot]

I would like to have a general principle of having string-named aliases for [Symbol.dispose]() whenever it is present, unless we're trying to explicitly discourage manual disposal, which we have no reason to do here. I think this is true of other Symbol-based protocols as well; e.g. I think whenever we have a [Symbol.iterator]() (on something which is not already an iterator) we should have a string-named alias for that as well (a principle we mostly already follow, with the exception of String).

(I've said as much elsewhere; e.g. Node now codifies this principle in their docs [point 4].)

I'm not really worried about the slight inconvenience for people writing their own GovernorTokens, since those people will be vanishingly rare compared to the consumers of GovernorToken.

[michaelficarra]

Does this mean you also have an opinion on #19? Include a prototype with a release method that defers to the canonical implementation in Symbol.dispose (and similar for async variants)?

I'm still leaning against this. As a consumer, if the symbols are the canonical interface, I don't think I'd ever use the string-named interfaces, just in case the Governor implementer either forgot to inherit from GovernorToken.prototype when creating tokens or forgot to install the string-named method.

[bakkot]

I'm neutral on #19. I don't think we should care very much about maximizing the convenience of people writing their own governors. But I'm fine with it existing.

As a consumer, if the symbols are the canonical interface, I don't think I'd ever use the string-named interface, just in case the Governor implementer either forgot to inherit from GovernorToken.prototype when creating tokens or forgot to install the string-named method.

I don't necessarily think symbols should be the canonical interface. But either way, as a consumer I would definitely always use the string-named interface, because it's way more convenient. I don't expect to be working with arbitrary library-defined GovernorTokens basically ever, and even in those cases I would just expect the library to define the full interface. I do not write code defensively against libraries having left out some method I'm expecting to be there.

[michaelficarra]

Well I don't think we can reasonably say that this interface is both "release" and [Symbol.dispose] and they must both be present and behave identically. That's more than a little strange.

[bakkot]

I would say that release is the canonical interface, and Symbol.dispose is provided on the built-in types for convenience of manual consumers.