-
Notifications
You must be signed in to change notification settings - Fork 123
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
Move option to emit struct names to PrettyConfig
#329
Conversation
efd2a8e
to
85a2136
Compare
PrettyConfig
85a2136
to
66816f8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice! Also, I believe this is backwards-compatible.
Edit: Actually, no, it's breaking pub fn new(..)
API.
I actually think that this is a bad idea and should be reverted. Emitting struct names is not only a matter of prettiness. Let's say I have two structs,
When serializing a Just emitting struct names is programatically (and visually) much nicer than putting all serializeable/signable types into an enum. |
This reverts commit 62db940.
This reverts commit 62db940.
Sorry,I don't understand the argument about cryptographic names and hashes. |
The fact that Let me give a more concrete example: you have a kind of decentralized business review platform where each customer has its own keypair and signs reviews:
If you just serialize, hash and sign the above structs without emitting struct names, any valid (In the example above, you'd probably just use an enum instead. But if you have more structs to sign and want absolute peace of mind, you'd have to put all your structs into an enum, which is just a pain to maintain and introduces new kinds of possible errors. Emitting struct names is a much simpler and more elegant solution.) |
Another more general argument is that since this has been merged, your |
* Move struct_names from Serializer to PrettyConfig * Update changelog
Fixes #200.