Implement call builder pattern to more closely match alloy APIs #115
Conversation
…0-ethereum into victor/use-risc0-main-on-main
…0-ethereum into victor/use-risc0-main-on-main
…e-risc0-main-on-main
austinabell
changed the title
| } | ||
| } | ||
|
|
||
| #[cfg(feature = "host")] |
There was a problem hiding this comment.
So far I have tried to have everything that depends on the host feature in the host module, this also eliminates the need for those ugly configs for imports.
But of course, this approach would reduce code locality, and that is a tradeoff. So let's see how everything looks after the consolidations and see which one makes more sense.
There was a problem hiding this comment.
Agree, I'm right on the fence with this, and just made a judgement call of what seemed most clean. No opinions here, so happy to switch if anyone shares an opinion!
| use std::fmt::Debug; | ||
| use test_log::test; | ||
|
|
||
| macro_rules! provider { |
There was a problem hiding this comment.
This was the only way I could think of to make the golden cache file generation a bit more streamlined. It also fixes the issue where the spec was not always provided (which was already an issue before this PR).
Happy to change it if there are any better suggestions....
|
We will probably have to wait until #110 is merged, though. |
|
should I cherry-pick commits to fix the unrelated commits on this PR or is it fine the way it is? (fine by me since squashed anyway) |
|
Let's just squash and merge |
More context here #91 (comment)
This is built on #110
Draft until:
ViewCallconstructorAlthough I think this API is better for now and to future proof, I don't feel strongly about any names or specific APIs. My goal was to try to match alloy as close as possible, while keeping necessary patterns or naming that existed before (also to minimize breaking changes like re-using
ViewCall. Opinions or comments welcome!This should only give deprecation warnings from 0.10
Details that might be missed:
newandpreflightare the constructors forContract. They both have thecallmethod at the end of the chain, but the guest one implicitly unwraps the error. I don't love this pattern, but I'm matching the existing onecontract.rsSteelEnvtrait the internal implementation is based on is kept pseudo-public, to avoid exposing the trait type to the public API. Just used to be able to useCallBuilderin a generic way internally.