Hmm, yea I was taking a look at it just now, and that makes sense.
Then here’s a followup question to take it in the other direction: In what parts of the codebase does it make the most sense to use the wrapped version? What is the original intention behind providing an
enum PublicKey and
enum PrivateKey wrapper in
sn_data_types? I wonder if there’s a document somewhere that indicates the use case a bit clearer, or if this could be added to the docs if it’s not there?
Seems to me from a quick GitHub search and through my own anecdotal code browsing, that these wrapped types don’t currently stand well on their own. Often importing
sn_data_types::PublicKey is accompanied by an import of
bls::PublicKey or some other library function. It seems a bit of “code-smell” that we have a wrapper that relies on the underlying implementation to be imported with it, no? Maybe I’m missing something? Does that indicate the wrapper needs to be fleshed out more? Or are we trying to mix apples and oranges too much?
In terms of keeping them in an enum, is there any place in code where it’s important
match on the key, and dispatch to a different handler depending on the key type? It seems to me, on first glance, to be the opposite, where we often rely on the underlying type of the key to be a specific variant.
This is all leading to the reverse possibility. Just thinking aloud, but would we be better served by re-exporting
sn_data_types and wrapping just the error types instead? It would still unify the dependency versions, but would allow each key type to be treated on its own terms