Skip to content
This repository has been archived by the owner on Apr 13, 2021. It is now read-only.

Return non-wrapped types from Invoice getters if possible #26

Closed
sgeisler opened this issue Feb 14, 2019 · 1 comment
Closed

Return non-wrapped types from Invoice getters if possible #26

sgeisler opened this issue Feb 14, 2019 · 1 comment
Assignees
Labels
design decision API design discussion enhancement New feature or request

Comments

@sgeisler
Copy link
Contributor

The Invoice type has the highest level of abstraction in rust-lightning-invoice and aims to provide an ergonomic API. @stetvenroose pointed out in #23 that the internal newtypes are rather inconvenient and I agree, but unfortunately we can't get rid of them.

I'd propose to at least make the Invoice interface as conevnient as possible by making the getters return the inner type of the respective newtype:

  • payment_hash should return bitcoin_hashes::sha256::Hash instead of Sha256
  • payee_pub_key and recover_payee_pub_key should return secp256k1::...::PublicKey instead of PayeePubKey
  • expiry_time should return std::time::Duration instead of ExpiryTime
  • min_final_cltv_expiry should return u64 instead of MinFinalCltvExpiry

@TheBlueMatt and @stevenroose do you think that's an improvement?

@sgeisler sgeisler added enhancement New feature or request design decision API design discussion labels Feb 14, 2019
@sgeisler sgeisler self-assigned this Feb 14, 2019
@stevenroose
Copy link

Copied from #23:

Yeah the code of this crate very much confuses me. The whole idea of keeping the fields around and so might have overcomplicated it.

Don't you think it'd be able to take an approach like @dongcarl's PSBT implementation where you just assign all fields during deserialization?

I don't know why the current design was built like it is, but reading the BOLT 11 spec, it seems to be quite similar to the PSBT format serialization.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
design decision API design discussion enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants