search

zingolabs / zcashrpc

An async zcashd RPC client rust crate.
MIT License
2 stars 1 forks source link

reincorporate explicit types that should not have been removed #32

Closed zancas closed 3 years ago

zancas commented 3 years ago

We shouldn't have removed the explicit types from client/subcomponents.rs this commit readds them.

zancas commented 3 years ago

@AloeareV what do you think of this?

AloeareV commented 3 years ago

Hm. I thought this entire business was because explicit Subcomponent Response types weren't scaleable, and needed to be factored out in favour of procedurally generated types. Do you mean we removed them too early?

zancas commented 3 years ago

No, I have miscommunicated.

Writing RPCResponse types down by hand.. i.e. typing each one out with one's keyboard, does not scale.

Therefore they need to be programmatically generated. We need a process that takes JSON as an input, and produces human-readable (ideally) standard Rust code. The output is not a call to a macro.. the output is Rust code.

It's fine.. probably the best way, to have a macro call be part of the code generation, but the macro call... is not the final product. To put it another way the end result is not a TokenStream the end result is a String-that-is-written-to-a-file.

The template for the pattern is the behavior of the "protobuf" system.

I know I have tried to express this idea both verbally and in keybase several times, but somehow I am not making it clear.

Perhaps I will make it it's own issue, then I will just repeatedly reference the issue.

AloeareV commented 3 years ago

Hm. I understand that we're going to have code that generates .rs file(s) with the types in them, and it well eventually look very similar to the current layout of Subcomponents. What I'm saying is: Hand-written RPC response types don't scale. Do we not want to remove the hand-written types until we're generating human-readable rust code in their place?

AloeareV commented 3 years ago

To clarify: I'm saying that I thought we wanted to remove the hand-written types, not the explicit types, but as these types are both, I thought we wanted to remove them due to their hand-written-ness, and replace them with the macro, and then upgrade the macro to write human-readable code.

zancas commented 3 years ago

Hm. I understand that we're going to have code that generates .rs file(s) with the types in them, and it well eventually look very similar to the current layout of Subcomponents. What I'm saying is: Hand-written RPC response types don't scale. Do we not want to remove the hand-written types until we're generating human-readable rust code in their place?

I think we want to hand-written stuff to be our model of what our machine generated stuff should look like.

zancas commented 3 years ago

To clarify: I'm saying that I thought we wanted to remove the hand-written types, not the explicit types, but as these types are both, I thought we wanted to remove them due to their hand-written-ness, and replace them with the macro, and then upgrade the macro to write human-readable code.

I think we should prove that our machine written stuff is morally-identical to the original handwritten stuff... before we remove any of it.

zancas commented 3 years ago

@AloeareV how do you feel about this PR? @dannasessha ?

zancas commented 3 years ago

I would like @dannasessha to review and merge this code, if it's acceptable.