Wasmtime GitHub notifications bot (Jul 21 2021 at 16:29): Wasmtime GitHub notifications bot (Jul 21 2021 at 16:29):fitzgen opened PR #3104 from some-api-docs to main:
<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
Wasmtime GitHub notifications bot (Jul 21 2021 at 16:29):fitzgen requested alexcrichton for a review on PR #3104.
Wasmtime GitHub notifications bot (Jul 21 2021 at 16:33):abrown submitted PR review.
Wasmtime GitHub notifications bot (Jul 21 2021 at 16:33):abrown created PR review comment:
Thanks for documenting this--super helpful!
Wasmtime GitHub notifications bot (Jul 21 2021 at 16:40):sunfishcode submitted PR review.
Wasmtime GitHub notifications bot (Jul 21 2021 at 16:40):sunfishcode created PR review comment:
Style suggestion: Instead of an absolute negative, "wasmtime will not [...]", say "Lazily populating exports makes instantiation faster, and that's a really good thing for many use cases".
Wasmtime GitHub notifications bot (Jul 21 2021 at 17:03):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Jul 21 2021 at 17:03):alexcrichton created PR review comment:
Personally I find this style of documentation to be helpful for a pretty small subset of people. Most of this can be understood by Rust & Wasmtime experts, but that's not necessarily who's always reading the documentation. I would instead perhaps recommend a style where we explain why the mutable context is used here and some benefits of that, but I wouldn't go into many details of "if we did this other thing it would have these implications".
Basically I don't want to draw too too much attention to this design decision because it's relatively minor compared to the rest of Wasmtime, and while it's important to be aware of it it's not necessarily too useful I think to consider what alternate implementation strategies were rejected when thinking about this. (tbh I never even considered using a lock or a cell, the mutability here just seemed natural)
Wasmtime GitHub notifications bot (Jul 21 2021 at 18:23):fitzgen submitted PR review.
Wasmtime GitHub notifications bot (Jul 21 2021 at 18:23):fitzgen created PR review comment:
(tbh I never even considered using a lock or a cell, the mutability here just seemed natural)
I would argue that this is only because you understand that it is doing lazy population and mutation under the covers though. I think most people would expect that getting an export is just reading a field or doing a hash map lookup.
Otherwise good points.
Wasmtime GitHub notifications bot (Jul 21 2021 at 18:26):fitzgen updated PR #3104 from some-api-docs to main.
Wasmtime GitHub notifications bot (Jul 21 2021 at 19:07):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Jul 21 2021 at 20:11):fitzgen merged PR #3104.
Last updated: Nov 22 2024 at 16:03 UTC