-
Notifications
You must be signed in to change notification settings - Fork 14
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
Think about ReadFrom/WriteToV2
one more time
#532
Comments
normally conversion to and from message to SDK entities should be done in exactly one place: https://pkg.go.dev/github.com/nspcc-dev/neofs-sdk-go/client and https://pkg.go.dev/github.com/nspcc-dev/[email protected]/pkg/network/transport respectively. V2-converters accidentally went beyond these two spaces of the system, so you are experiencing a headache
|
It does not matter if I need to use it in a single package or in a dozen packages, if I write tests, or if I am a regular SDK user. I just do it sometimes. The same way I encode cID and oID and maybe some other things that I forget about now. I just need more lines of (boilerplate) code for no reason (usually).
How can this help me? |
@carpawell, u've not described the exact problem yet in form: i want this but the only way is to cast into v2. If u have the case, report it if u have some useful helpers, just propose it in PR or create an enhancement issue |
Why do we need cases for exported methods in the "SDK" repo? We already have them (methods) and we are not gonna delete them. Why do I need this? Why this file has to have
The same way I have to encode/decode addresses, IDs, etc. Why? That is not about V2 only.
We are discussing such an issue right now. |
|
Problem
With
ReadFromV2
it mostly always required more lines of code to achieve the same thing withToV2
andFromV2
that allocate structs inside. We can think about some helpers placed near the methods.Context
Updating SDK in some old code or writing a new code can be annoying with these totally necessary lines (when there is no need to reuse struct b/w reading or writing protocol conversions). This approach was presented in #170 and we had some long discussions, it was not an easy change.
The text was updated successfully, but these errors were encountered: