proposal: refactor the View creation to be a Builder pattern

[dhuseby]

After looking again at the interface for getting the different views on a Multikey, I think it makes sense to refactor that to be a Builder pattern. The general idea is to do the following:

1. initialize a builder passing a reference to the multikey: ViewBuilder::new(&multikey)
2. optionally add in the codec and view creation callback: .with_local_codec(codec, |mk, view_id| -> Box<dyn View> => { .. })
3. call the build function to get the view: .build()

The main motivation for this comes from the proposal going into the multikey spec to support custom protocol keys: cryptidtech/provenance-specifications#4

By re-arranging the view building to a builder pattern we enable custom protocol implemenations to pass in callbacks that the builder will call to construct the view. This is how we can support user-defined custom protocol keys in the cleanest possible way. For the "standard" key types, the builder just calls the correct functions in the View interface implementation to construct the standard view.

This will be a breaking change since it will change the Multikey interface.

[dhuseby]

@DougAnderson444 ^^^

[DougAnderson444]

I'd like to take this occasion to note that if the closure arg such as |mk, view_id| -> Box<dyn View> => { .. } does not capture any of its environment, I'd prefer to see those types of arguments as Impl Trait so that the types are clear and documented to the consumer.

[dhuseby]

Can you give me an example of what you mean?

[DougAnderson444]

What I was thinking of is either capture the environment (less preferred):

let mk: Multikey = Default::default();
let view_id: Id = Default::default();

.with_local_codec(codec, || -> Box<dyn View> {
    // use mk and view_id to create view
}) 

or do something like this, which give us rustdocs, access to RPITIT, option to persist struct state, etc.:

/// Implement this trait in order to create a [View]
///
/// # Example
///
/// We get full documentation here because we use a Trait
/// instead of a closure.
/// We can use other Rust features that closures can't 
/// give us yet like async or using
/// Return Position Independent Types in Traits (RPITIT)
pub trait IntoView {
    /// Docs and examples for creating a view, etc.
    fn create_view(&self) -> impl View; // <== this could be impl Future for async

    /// Mutable version to allow persisting state in the struct
    fn create_view_mut(&mut self) -> impl View;
}

/// My struct which will hold the params necessary to impl the Trait
struct MySigner {
    mk: Multikey, 
    view_id: Id // or perhaps a .id() -> Id method.. it's up to the user
}

// user impl
impl IntoView for MySigner {
    fn create_view(&self) -> impl View {
        // use self.mk and self.view_id to make View
    }
}

// final use
// ..
.with_local_codec(codec, my_signer)
// ..

// later in the method
fn with_local_codec(codec: Codec, signer: impl IntoView) {
    // ..
    signer.create_view();
}

[dhuseby]

I like where you're going with this. Thanks for the information. I like it.