Implement Transaction type on Either type

[neithanmo]

Motivation

See #2051

Solution

A new module called either is added, this is useful to handle different transactions types
as it implements Transaction trait. The Either type here is a bit similar to this, however a custom one might be easier to customize.

PR Checklist

• [x ] Added Tests
• [x ] Added Documentation
• Breaking changes

[mattsse]

we can simplify this a lot if we reuse the existing Either type from the either crate and implement our Tx traits for that type

[neithanmo]

we can simplify this a lot if we reuse the existing Either type from the either crate and implement our Tx traits for that typeD

@mattsse
I think, the wrapper approach sacrifices Rust's pattern matching ergonomics:

// With wrapper (cumbersome):
if let Some(tx) = self.as_left() {
    tx.authorization_list()
} else if let Some(tx) = self.as_right() {
    tx.authorization_list()
} else {
    unreachable!()
}

With direct Either enum (clean):

match tx {
    Either::Left(t) => t.authorization_list(),
    Either::Right(t) => t.authorization_list(),
}

While reusing either crate saves implementation code, it significantly impacts usability. Unless we make the inner field public (breaking encapsulation) or implement our own enum directly(as it is currently implemented here), we lose the clean pattern matching that makes working with sum types handy and easy to use and clean.

[DaniPopes]

What do you mean? https://docs.rs/either is exactly the same as what you defined

[neithanmo]

What do you mean? https://docs.rs/either is exactly the same as what you defined

Yep, it is the same to take advantage of the ergonomics of sum types.
defining it as a wrapper:

pub enum Either(pub either::Either);

would require an indirection layer, assuming inner field is defined as a public:

match tx_either.0 {
       either::Either::Left(..)
       either::Either::Right(..)
}

if defined as private would be even less ergonomic.

Alright, i will change this to use a wrapper type with the inner field public

[neithanmo]

What would be a good name here?

• Either could cause name collision with the original either crates in users code
• TransactionEither seems good but?

What do you think? @DaniPopes @mattsse

[DaniPopes]

You shouldn't need a wrapper type at all, all the traits you want to implement are defined in this repository so you can just implement them on the foreign type

[neithanmo]

You shouldn't need a wrapper type at all, all the traits you want to implement are defined in this repository so you can just implement them on the foreign type

Done !!