Byron/prodash

Support dyn `Progress`

NobodyXu opened this issue · 1 comments

I would like to add another provided method to Progress, suitable for trait-object usage to avoid monomorphization:

triat DynProgress: Send + Sync {
    // Required methods
    fn add_child(&mut self, name: String) -> BoxedDynProgress;
    fn add_child_with_id(
        &mut self,
        name: String,
        id: Id
    ) -> BoxedDynProgress;
    fn init(&mut self, max: Option<Step>, unit: Option<Unit>);
    fn set(&mut self, step: Step);
    fn step(&self) -> Step;
    fn inc_by(&mut self, step: Step);
    fn set_name(&mut self, name: String);
    fn name(&self) -> Option<String>;
    fn id(&self) -> Id;
    fn message(&self, level: MessageLevel, message: String);

    // Provided methods
    fn unit(&self) -> Option<Unit> { ... }
    fn max(&self) -> Option<Step> { ... }
    fn set_max(&mut self, _max: Option<Step>) -> Option<Step> { ... }
    fn inc(&mut self) { ... }
    fn counter(&self) -> Option<StepShared> { ... }
    fn info(&self, message: String) { ... }
    fn done(&self, message: String) { ... }
    fn fail(&self, message: String) { ... }
    fn show_throughput(&self, start: Instant) { ... }
    fn show_throughput_with(
        &self,
        start: Instant,
        step: Step,
        unit: Unit,
        level: MessageLevel
    ) { ... }
}

/// An opaque type so that `gix` can internally change its implementation details,
/// e.g. use an `Arc` instead of `Box`, or even inlining the progress.
pub struct BoxedDynProgress;

impl BoxedDynProgress {
    pub fn new<P: Progress>(p: P) -> Self;
}

impl DynProgress for BoxedDynProgress {
    // ...
}

impl Progress for BoxedDynProgress {
    type SubProgress = Self;

    // ...
}

trait Progress {
    // ...

    // Provided method
    fn into_dyn_progressive(&mut self) -> DynProgressRef<&mut Self>;
}

pub struct DynProgressRef<'_, T>;

Originally posted on Byron/gitoxide#987

Byron commented

As we are aligned with what to generally do, I think it's absolutely OK to skip issues and go right for PRs. They are easier to work with as well thanks to actual code being available. If that's OK with you, please feel free to close this in favor of the PR.