Tree-shakeable protocol definitions

[legendecas]

The current design installs symbol-keyed methods onto the class prototype via implement. Even if a consumer never calls a particular protocol method, it is bundled and attached to the class because a bundle would not be able to infer if it would be used or not. Protocol implementations are non-tree-shakeable.

A library may define many protocols and methods, but a given consumer may only use a few. The current design forces shipping all of them.

Sparked by the recent TC39 tree-shaking discussion, I'm wondering if we could make protocols not mixing into the implementing class. Instead, the consumer imports the protocol and applies it via extension-call or call-this syntax:

import { ProtocolA } from 'some-protocols';
const instance = new MyClass();
instance::(ProtocolA.methodFoo)();

In this case,

• the protocol is applied by the user, not the class author (this could conflict with the proposal motivation, but could be a bonus point as extending existing classes does not need patching the target class prototype).
• the class prototype does not mix-in new properties (this could also conflict with the proposal motivation, but would be necessary for tree-shaking).
• since protocols are frozen objects, bundlers can also eliminate individual unused methods within an imported protocol.

This enforces explicit references to each protocol and each protocol method used in user code.

Might be related: #46

[ljharb]

Why would a bundler not be able to infer if it's used or not?

Either way, the point of "first-class protocols" is to reify the protocol system we already have, which requires methods mixed into the class (like Symbol.iterator, for example).

[samualtnorman]

my thinking is that if a symbol is never referenced outside its protocol method definition, it can be more-or-less safely pruned

[ljharb]

Just like any object with properties, yes - but also, if the object is passed anywhere, you can't prune anything (unless you follow its path and ensure it's not reflected over)

[samualtnorman]

it is way harder with regular object properties since strings are not unique whereas symbols are

[ljharb]

again, registered symbols are the same as strings, and a symbol (even a non-registered one) can come from anywhere just like a string can. I'm very skeptical it's any easier with symbols than with strings.

[samualtnorman]

wait, as in protocol symbols will effectively be Symbol.for()?

[ljharb]

no, definitely not registered symbols (what Symbol.for produces) :-) I'm saying that for non-registered symbols, you still have to track the entire lifetime of the symbol to determine if it's unused, including that nobody has ever reflected on the object - which seems harder to me than determining if a string is used for lookup.

[samualtnorman]

okay yeah you're right if reflection or index notation where the key is not compile time known is being done on the protocol object, you can't really safely prune any methods.

but I think as long as a protocol is only ever being referenced in non-computed member expressions, which I think will be likely for most code, unreferenced methods can be safely pruned.

and at least if something non-compile-time-known is being done on a protocol, at least its isolated to that protocol

[ljharb]

A protocol isn't useful unless it's shared, and the protocol object holds a reference to all the symbols, and could be reflected on at any point in the program.

[samualtnorman]

what do you mean when you say shared? I can think of 2 things, passing to a function, and exporting. you obviously don't want to prune anything if it's being exported, you'd leave that up to consumers who might be bundling and then prune. for passing to functions, yeah that's a reasonable usage that didn't come to mind. you would need to follow the parameter references or give up if ...args is involved.

[ljharb]

I mean exported, yes. A protocol's value is that anyone can access it and implement it.

[samualtnorman]

ah well I'm not talking about that. you don't want to prune anything being exported regardless of protocols. that would happen after bundling

[ljharb]

Right - which means "tree-shakeability" basically doesn't ever apply to protocols since protocols are almost always going to be exported somehow.

[samualtnorman]

ah so by tree shaking, you're solely talking about pruning unused imports/exports. regardless of what we call this type of pruning, I think protocols solve the problem people want solved when it comes to pruning unused methods

[ljharb]

Yes, that's what "tree-shaking" means - tooling that attempts to delete unused code.