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.
#endo-branch: markm-flip-which-symbols-are-passable
linked with endojs/endo#2777
closes: #XXXX
refs: endojs/endo#2777 #11337
Description
endojs/endo#2777 will flip which symbols are passable. This PR prepares agoric-sdk to work both before and after that transition by abstracting the functions for creating passable and unpassable symbols by name.
Security Considerations
If this PR does work both before and after, none.
Scaling Considerations
Other than those already explained in endojs/endo#2777, none
Documentation Considerations
none
Testing Considerations
Other than providing the abstractions in ses-utils.js, the only non-test *.js file that needed revision was bufferedStorage.js. Aside from it, all other uses of symbol as of the first commit are only for testing.
t.deepEqual
whose callers had to be revised in fix(pass-style)! flip which symbols are passable endojs/endo#2777. The new distributed object semantic preserves equality for the "same" passable symbol according to its own equality predicated. But it does not preserve JS identity. We need to fix these callsites.Upgrade Considerations
The wire and durable representation of passable symbols in general will be the same. This is not true for well-known unregistered symbols. This PR is experimentally linked with endojs/endo#2777, which provides some legacy support specifically for
Symbol.asyncIterator
. We'll see what problems remain.