-
Notifications
You must be signed in to change notification settings - Fork 12
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
core data types: ByteArray test / interop #48
Comments
Above I'm quoted as saying
Since then, at |
Please join me in very seriously expressing a preference for one of the following in reactji.
|
@jar398 Let’s put a record of results on the agenda for next meeting. |
Can we please postpone choosing a name until we have a test case demonstrating interoperability? |
Just saw this. At the OCapN meeting just now, we did go with the poll winner, "byte array". I would prefer not to revisit this, but to accept it as the winner. How might getting to an interoperable test case affect our name choice? |
I can join you in hoping that it doesn't. I would very much like to establish a pattern where we have a test case in place when we decide issues, though. So I suppose as long as noone aims to close this issue before we have a test, I'm content. |
I like tests and agree we should settle many issues only after we have tested code on both the Agoric and Spritely platforms. I do not understand how it would be mechanically possible for the name of an entity in the language-agnostic model could cause a concrete test to fail. I however can see how a cross-language test might reveal that the type should not exist in the data model at all. |
Inclusion of the datatype seems to have consensus, but Agoric lacks support, so we can't demonstrate interop yet.
A test that all 3 of Spritely, Agoric, and capnp pass would be great.
ref @erighs #5 (comment)
The text was updated successfully, but these errors were encountered: