-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider renaming error resource to-debug-string
to to-string
#55
Comments
Just to give some context, an important consideration of the name |
Right, in JS, |
Thanks, I didn't have enough JS context to understand that. It is troublesome to select names so that generated code works idiomatically in a given guest or host language or ecosystem. These definitions have to work in any language that can target WebAssembly. If we had to consider each target language idiom, that would put a huge burden on interface authors (e.g. in this case, I don't know JS idioms, should I be expected to learn them to author wits?) and we will always end up disappointing some language or another where they inevitably conflict. Instead, I think the best way to remedy this is for each language's bindgen tools to be configurable (or otherwise clever enough) to rename a given wit name to whatever name is idiomatic for that language. In this case, it seems reasonable for JS guest and host bindgens to map each use of the |
Saying we are open to embedding-specific mappings for error resources would definitely be interesting to explore here. I wonder if it would even make sense to consider mapping the error types to subclasses of real JS errors. |
The discussions around the design of |
I've found that if I have a resource with a
to-string
that coerces totoString
in JavaScript and immediately supports logging correctly etc due to JavaScript's blessed handling of thetoString()
method.If the goal was to avoid this kind of conflation due to conflicts, I just wanted to mention that in general using the
to-string
name actually does what we do want in this error resource case for JavaScript, so could be worth considering aligning on. So far as other ecosystems don't have reasons to inhibit its use, JavaScript is certainly not a blocker and in fact if anything a reason to useto-string
.The text was updated successfully, but these errors were encountered: