-
Notifications
You must be signed in to change notification settings - Fork 378
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
Better names for types #665
Comments
Thanks for writing this up! I re-tagged it for discussion since there's nothing broken you just want to discuss some naming improvements. My two cents on the naming, your suggestions sound fine to me, but we need to be careful not to change names that break a public API unless there is compelling reason to do it. Don't forget some users maybe forced to change their code for only a small readability gain. |
Mh, I don't really like |
This sounds like something to tackle as part of the 1.0.0 API changes. |
These look like small changes but I think we should move to the 2.0 milestone. |
Already fixed. |
Description
After going through the codebase of the
wallet
module, I felt like we could do with some improvements in naming. I will list some suggestions below.ChangeSpendPolicy
->InternalSpendPolicy
bdk/src/wallet/tx_builder.rs
Lines 742 to 751 in dd51380
Right now we do not keep track of which outputs are change/not-change in the database. We only differentiate based on whether the
scriptPubKey
is derived from the external descriptor or internal descriptor.bdk/src/wallet/tx_builder.rs
Line 145 in dd51380
Similarly, this field should be called
spend_internal_policy
.LocalUtxo::is_spent
->LocalUtxo::is_used
bdk/src/types.rs
Lines 134 to 135 in dd51380
Considering that UTXO is an acronym for "Unspent Transaction Output", this naming is very confusing. "Spent" for me means that the transaction is already included in a mined block. By calling it
is_used
, we will know whether it has already been used as input during tx creation.The text was updated successfully, but these errors were encountered: