Rename ExternalValues to ImportValues; order of params in ImportFunction,HostFunction.
#589
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follow up to #527
Hopefully last big rename (related to this, at least) before the RC 😅
After chatting with @andreaTP, we agreed that
ExternalValues, from the perspective of an end user, was confusing naming ("external to what?"). We came up withImportedValues.To be honest, my original objection with
HostImportswas about them beingHost, not `Imports" :)<module,name>).ExportFunction)we do "lose" the parallel with the spec, but this is less of an issue, because we only use these
ImportValuesas, duh, values imported byInstances. We never returnImportValuefrom anexport*()-kind API, so everything should workOrder of Parameters for External/HostFunction
In this PR I am also changing, again, the order of the parameters for
ImportFunctionbecause the old constructor "broke" the signature into two pieces, i.e. the handle was between the names and the types:vs:
which I think is clearer. This change is in the last 2 commits, for easier review.