Open tcharding opened 3 months ago
However qualifying paths like
bitcoin::Transaction
do not really add any additional clarity.
I wouldn't mind dropping them here, but FWIW I think they do add clarity -- when I'm working I often also have elements::Transactions
also in play. Though I appreciate this crate is bitcoin-only and everything it does is designed to work with bitcoin transactions.
Note also that if the
bitcoin_primitives
crate comes into play thebitcoin::
paths will get a bunch longer/noisier (excluding using any alias magic).
Yeah, this is unfortunate. I don't want to see bitcoin_primitives::Transaction
everywhere. I wouldn't mind primitives::Transaction
but that really does provide no value.
I guess we should just drop the bitcoin::
qualifying types. Specifically with PublicKey
we have some ambiguity so maybe we should import the secp one as SecpPublicKey
and then use PublicKey
for the bitcoin one.
hmm, perhaps use bitcoin_primitives as bitcoin
would be beneficial then, and keep bitcoin::Transaction
.
I think that'd be too confusing because there is a real bitcoin
crate that people would think we were using.
Probably we should just drop the prefixes and use bare Transaction
.
This crate uses qualifying paths for types eg,
bitcoin::PublicKey
andsecp256k1::PublicKey
. I understand that this adds clarity, especially for types that exist in multiple places (like the given example). However qualifying paths likebitcoin::Transaction
do not really add any additional clarity.Note also that if the
bitcoin_primitives
crate comes into play thebitcoin::
paths will get a bunch longer/noisier (excluding using any alias magic).Would we be open to changing the qualifying path strategy in this crate? One suggestion would be to only qualify non-bitcoin types eg., still qualify the
secp256k1
types.