Skip to content
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

@custom_serialize / @custom_deserialize DSL #234

Merged
merged 6 commits into from
May 18, 2024

Conversation

rooooooooob
Copy link
Collaborator

@rooooooooob rooooooooob commented Apr 26, 2024

e.g. ; @custom_serialize write_hex_bytes

For specifying externally-provided functions for arbitrary encodings/cbor details for (de)serialization.

Allowed at both the type-level (affecting everywhere it's used) or at the field-level (overrides type-level if present).

Example use-case: CML's PlutusData's Bytes (and BigInt) variant doesn't use arbitrary CBOR bytes strings but instead follows a specific chunking format. We used to hand code this but now we can just put this in the DSL.

This is particularily useful for people generating plutus-datum-based CDDLs. It could also be used to allow for utf8 text (rust API) to be (de)serialized to bytes to be encodable as a datum.

e.g. `; @custom_serialize write_hex_bytes`

For specifying externally-provided functions for arbitrary
encodings/cbor details for (de)serialization.

Allowed at both the type-level (affecting everywhere it's used) or at
the field-level (overrides type-level if present).

Example use-case: CML's PlutusData's Bytes (and BigInt)  variant doesn't use arbitrary
CBOR bytes strings but instead follows a specific chunking format. We
used to hand code this but now we can just put this in the DSL.

This is particularily useful for people generating plutus-datum-based
CDDLs. It could also be used to allow for utf8 text (rust API) to be
(de)serialized to bytes to be encodable as a datum.

TODO:
[ ] tests for preserve-encodings
[ ] tests for tagged/otherwise extra encoding details over top of this
@@ -104,6 +104,61 @@ foo = uint ; @newtype @custom_json

Avoids generating and/or deriving json-related traits under the assumption that the user will supply their own implementation to be used in the generated library.

## @custom_serialize / @custom_deserialize
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's not necessarily obvious from the docs that what comes after these is a user-specified arbitrary string (i.e. write_hex_string is not some magical thing built into cddl-codegen, but rather an arbitrary string we just used as an example)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a short paragraph explaining that the string is just directly called and thus must be qualified or imported.

Copy link
Collaborator

@SebastienGllmt SebastienGllmt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM other than the comment about the docs

@rooooooooob rooooooooob merged commit 200f1fe into master May 18, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants