Idea: provide a clean, native ability to produce examples of datums, redeemers, or transactions #582
Replies: 4 comments 1 reply
-
I like the idea. We could very much attach "examples" to type definitions, and have them generated as build artifacts. |
Beta Was this translation helpful? Give feedback.
-
I like the idea in principle but I'd be against having this kind of thing exist at the expression level. Expressions need to be able to map to something that runs on the VM and we could consider the behavior of persist to be compile time. So let's brainstorm some more on alternative ways to express this. |
Beta Was this translation helpful? Give feedback.
-
@rvcas what are your thoughts on a top-level object, similar to
Or maybe more like a public constant
|
Beta Was this translation helpful? Give feedback.
-
What is your idea? Provide a use case.
One of the most important tools when trying to understand a set of contracts, or test it in the real world, is the ability to easily construct and persist examples.
I had two ideas for doing this natively in aiken:
or, if you don't want to add another keyword, another builtin like
trace
that saves to a file:Why is it a good idea?
Allowing developers to easily encode examples of their contracts is helpful in several ways:
What is the current alternative and why is it not good enough?
One option is to do something like this:
Which prints it as part of running tests, which can be cumbersome
Another option is to generate examples from Lucid, but this risks getting out of sync with the code, as LSP refactoring rules (as we add them) won't be aware of this code. It's also way less ergonomic.
Another option is to just build them by hand and put them in the repository, but this suffers from the same problems.
Beta Was this translation helpful? Give feedback.
All reactions