Repository navigation
Consider adding support for identifier aliases #312
Description
Over in #311, @oovm points out that the fact that components broadly include identifiers in their public interfaces means that it's hard to fix naming mistakes in stable APIs.
I wonder if it might make sense to explicitly support aliases for identifiers in all or most positions to address this: for interface, type, and function names, but ideally also for parameter and return value names.
I think a good way to integrate this would be to introduce a specific structured annotation for aliasing, and support that in all places where an identifier is allowed.
Bindings generators could then use these annotations to generate bindings for all the aliases, and have them use the original identifier internally.
(And if we want to fix a naming mistake, we could maybe do so by changing the name, but introducing an alias for the old name.)
Activity
oovm commentedon Feb 28, 2024
I wrote a simple spell check tool: wit-spell-check
This is the inspection result:
timestamp[method]descriptor.set-timestypeswasi:filesystem@0.2.0timestamp[method]descriptor.set-timestypeswasi:filesystem@0.2.0timestamp[method]descriptor.set-times-attypeswasi:filesystem@0.2.0timestamp[method]descriptor.set-times-attypeswasi:filesystem@0.2.0param[static]response-outparam.settypeswasi:http@0.2.0len[method]input-stream.readstreamswasi:io@0.2.0len[method]input-stream.blocking-readstreamswasi:io@0.2.0len[method]input-stream.skipstreamswasi:io@0.2.0len[method]input-stream.blocking-skipstreamswasi:io@0.2.0len[method]output-stream.write-zeroesstreamswasi:io@0.2.0len[method]output-stream.blocking-write-zeroes-and-flushstreamswasi:io@0.2.0src[method]output-stream.splicestreamswasi:io@0.2.0len[method]output-stream.splicestreamswasi:io@0.2.0src[method]output-stream.blocking-splicestreamswasi:io@0.2.0len[method]output-stream.blocking-splicestreamswasi:io@0.2.0lenget-insecure-random-bytesinsecurewasi:random@0.2.0lenget-random-bytesrandomwasi:random@0.2.0datagrams[method]outgoing-datagram-stream.sendudpwasi:sockets@0.2.0lukewagner commentedon Feb 28, 2024
Once things are immutably standardized, I could perhaps see this idea making sense as a way to avoid breaking changes while fixing names. Given that breaking source code is still a breaking change, we'd have to think through carefully how such aliases interact with semver. But in a pre-1.0 timeframe, since we're definitely allowing ourselves to make breaking changes, it seems simpler to just improve the names in each 0.x release (which will be trivial to adapt via component wrapping+re-exporting/importing), and then consider this feature in the lead up to stable 1.0.
oovm commentedon Feb 28, 2024
This mechanism is very common in serialization frameworks. Serialization must ensure that messages sent by previous versions are still valid, so the rename mechanism is widely used.
tschneidereit commentedon Feb 28, 2024
Oh yeah, I should've emphasized that I don't think we should use a mechanism like this pre-1.0. I was more generally thinking about how to handle this on the long-term.
(Whether we actually want to break arbitrary names in each 0.x release or queue them up for one big 1.0 breakage event is a different question, where I'd slightly lean towards the latter, but that's obviously not a topic to discuss here.)
pchickey commentedon Feb 28, 2024
This is a great discussion! Its really cool to see
wit-spell-check, if that tool had existed prior to stabilizing 0.2.0 we probably would have been nudged to turnsrcandlenintosourceandlength. Personally I believe thattimestampanddatagramsare good identifiers that are just missing in the dictionary, but we dont need to paint that bikeshed here.I think there is value in using an aliasing mechanism pre-1.0, which is to make sure that it is supported correctly throughout the ecosystem so that, if we really need to use it in anger post-1.0, its ready for use.