lukewagner
commented
5 months ago Good questions! So, when packaging up an implementation (like unicode-math-class or string-width in your examples), there's ultimately only one thing you need to name, which is the package name of the component implementation (just like in npm or cargo, where every package is an implementation package). Clients of this component implementation only need to know this one package name because the client tooling can extract from the component implementation all the necessary WIT information needed to generate client bindings (component binaries embed all the type information needed). You could sortof think of it as-if the package name of a component implementation also implicitly names "the world targeted by this component".
This is all in contrast to the situation where we're defining standardized interfaces and worlds as part of WASI or as part of some platform vendor's public interface. In these scenarios, there is no component implementation (no executable code being published), and thus we want only the type information, and so we have this regular encoding of pure WIT information into a component binary (as named exported component types).
Now, with that distinction made, when you are authoring a component that you want to later publish, you may need to write some WIT to specify the world you're targeting. You don't always have to, of course: if you're targeting a standard or platform-defined world, you just name the published WIT world (in your languages' appropriate buildconfig) and you're done. Alternatively (and increasingly over time), your language toolchain may allow you to define your component's type using source-language types and the toolchain then infers the target world from those types (e.g., mapping a Rust str to a C-M string). But in general, you may of course want to explicitly author a target world in WIT to have full explicit control (or express something you can't otherwise). And in this scenario, when you're writing WIT, WIT currently makes you specify a name for the target world, but in fact this world name doesn't actually appear in the final binary -- it's forgotten as part of compilation. For this reason, I've been thinking that we should probably allow a different "mode" of WIT where you (1) don't have to declare a package name, (2) get to write a single unnamed world that is understood to be "the target world". You can't package this WIT but by definition you don't want to -- you just want to feed this WIT into your language toolchain to author a component implementation (that you do want to publish). However, until we do that (or something else to address this use case), I wouldn't care about the world name (and naming scheme) when authoring a component, since whatever world name you write is ultimately forgotten.
I hope that helps! Happy to discuss more. (Also CC @alexcrichton for other thoughts, since this is something we've talked about before.)
jcbhmr
Here's a concrete example: If I want to turn this very simple Rust package https://docs.rs/unicode-math-class/latest/unicode_math_class/ into a WebAssembly component using https://github.com/bytecodealliance/cargo-component, what should I call the package, world, and interface?
For instance in the example Rust package, there's these levels of hierarchy:
serde::deso it's just the root module.In my brain those map relatively cleanly onto the package/world/interface model like so:
jcbhmr:unicode-math-classfrom my username + Rust package name. Sorta Docker-like two-part names.unicode_math_classunicode-math-classdue to no underscoresenum math-class {}inside an interface... but theMathClassis in the root module... What should I do? Is there a naming convention likeinterface crate { ... }? Ormod,root,module,iface,exports,main,lib,it,default, or something else? Single metacharacters like$,_,-aren't allowed 😢. If it had any sub-modules I guess those would map well toserde::de=>world serde {}; interface de {}.WIT snippet of that
```wit package jcbhmr:unicode-math-class; world unicode-math-class { // Can't export enum without a wrapping interface! What do you call the interface tho? export x: interface { enum math-class { ... } // No consts; compromise with getter func. revision: func() -> u8; // No char type; compromise with string. class: func(c: string) -> math-class; } } ```Is there a better way? 🤔
I'm looking for the convention. Or just some general "well here's what I do" ideas. I'm having decision paralysis and I'd like to get some other opinions besides my own biased one.
To add another example to my question: what about other languages? Another ezpz to-WASM language besides Rust is JavaScript https://github.com/bytecodealliance/jco#componentize
Here's my guess as to how something like https://tsdocs.dev/docs/string-width might be paralleled to WASM component WIT:
You've roughly got these hierarchical levels:
./(nostring-width/emojifiersub-exports)defaultfn andOptionstype in this case.In my brain I think that could be modeled as:
jcbhmr:string-widthsince I'm publishing it + package namestring-width=>world string-width {}butstring-width/emojify=>world string-width-emojify {}. Each world is an "entrypoint" set of imports/exports just like an ES module is.interface exports { default: func(...) }by just putting thefunc()on the world. But that doesn't work for modules that export enums, records, or resources. Specifically theoptionsbag record.WIT snippet of that
```wit package jcbhmr:string-width; // 'import {...} from "string-width"' world string-width { use options.{options}; // ugh. now the function is free of an interface but the record type // needs one. you might as well just stick them both in the interface? export default: func(string: string, options: optionIs there a better way? 🤔
no, the
string-width/emojifyexport doesn't actually existAs you might be able to tell, I'm a bit puzzled about when/how to use interfaces and how to name them idiomatically when they get in the way of flatter hierarchies. I'm trying to understand the concepts that package/world/interface are supposed to represent and apply them to existing programming concepts that I know. Thanks for reading my TED talk lol
p.s. has this already been discussed somewhere/somehow? it must've...