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

[Feature] Simple API to resolve json-abi item types #210

Closed
DaniPopes opened this issue Jul 26, 2023 · 8 comments · Fixed by #271
Closed

[Feature] Simple API to resolve json-abi item types #210

DaniPopes opened this issue Jul 26, 2023 · 8 comments · Fixed by #271
Labels
enhancement New feature or request

Comments

@DaniPopes
Copy link
Member

Component

dyn-abi, json-abi

Describe the feature you would like

Example: in ethabi you can just call Function::encode_input to ABI-encode data with the function's selector and inputs. cc @prestwich

Additional context

No response

@DaniPopes DaniPopes added the enhancement New feature or request label Jul 26, 2023
@davebryson
Copy link
Contributor

I'm experimenting with this now to get a better understanding of alloy's APIs. What's the intended replacement forethabi Token in this context ... SolType? Thanks!

@prestwich
Copy link
Member

DynSolType is roughly equivalent to ParamKind

The way i would to this is extending the Resolve trait in dyn-abi to have a method that both resolves + encodes

@davebryson
Copy link
Contributor

davebryson commented Aug 6, 2023

Here's one approach as a method on Function

pub fn encode_input(&self, args: DynSolValue) -> Result<Vec<u8>> {
   let input_types = self
            .inputs
            .iter()
            .map(|i| i.resolve().expect("valid type"))
            .collect::<Vec<DynSolType>>();
   
    if !input_types.matches(&args) {
            Err(...)
    }
      
    let encoded_args = args.encode_params();
    // prepend selector... etc...
}

I'm actually working on a pull request for this. However, this approach requires json_abi to depend on dyn_abi which already depends on json_abi.... which depends on ... resulting in a cyclic deps problem. Any thoughts on how to get around this?

@prestwich
Copy link
Member

yeah, the circular dep is why we need to put this logic in the Resolve trait in dyn-abi. json-abi is strictly a dat format, and should not rely on the type system representation in dyn-abi

@davebryson
Copy link
Contributor

davebryson commented Aug 6, 2023

@prestwich Ok, I think I understand what you're after now. A trait is needed in order to implement this logic for Function in dyn-abi but it would really only be implemented once (for Function). Is this what you envision?

@davebryson
Copy link
Contributor

@DaniPopes Following on to this, is there interest in taking a similar approach to provide support for something like event.parse_log() to parse the log into DynSolValues?

@prestwich
Copy link
Member

@DaniPopes should we come up with a struct that represents Events?

struct DynEventType {
    topics: [Option<DynSolType>; 4],
    body: DynSolType
}

struct DynEvent {
    topics: [Option<DynSolValue>; 4],
    body: DynSolValue
}

@davebryson
Copy link
Contributor

@DaniPopes @prestwich I'm happy to work on this once you decide on the direction. I've already roughed out an initial solution

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants