Closed matklad closed 3 years ago
To support the same set of choices would take 24 functions for encoding (default/custom alphabet no check byte/check byte/check byte and version 4 output types); or probably 6 or 7 encoding functions (base64
is missing functions for writing to an existing Vec<u8>
or &mut str
) + passing a config struct around like base64
does, which is essentially just an inverted builder pattern and I find more annoying to read than a fluent API.
I realize the API isn't the simplest, but that's why I went example heavy showing pretty much every variation, it shouldn't really be necessary to understand EncodeTarget
to use it.
That's fair!
it shouldn't really be necessary to understand EncodeTarget to use it.
That depends on the user: I have a quirk where I basically always ignore the docs for a crate and go directly to source code instead.
I guess, I am still pretty confident that base64-style API is possible (they have config, and the set of functions they provide (+ read/write/display modules) covers all necessary use-cases, if not all possible use-cases) and would work for me personally better, but I see how other people might have a difference design preference!
As a new user of base58, I need to understand how it works and how to use it. The current setup with
EncodeBuilder
struct andEncodeTarget
is not trivial -- it took me some time to wrap my head around the crate's API. I suggest taking inspiration from base64 API:https://docs.rs/base64/0.13.0/base64/index.html#functions
it is based around functions and is much easier for me presonaly to understand.