Rolling out a Pipeline type system for dispatching on analysis details

[SamuelBrand1]

          could we be really fancy and have a pipeline type and then dispatch on standard function names to make it really easy to overload parts of the pipeline? Then to change the analysis you would just change the target type and have a write your own new methods where you wanted?

Originally posted by @seabbs in #217 (comment)

I think this is a really neat idea. I'm not implementing this in PR #217 but I think we should keep this idea going.

[seabbs]

We would want the default to depend on a abstract type right with a specific implementation for our analysis so that others could easily branch off our defaults?

To make this truly generic it would suggest two modules:

• EpiAwarePipeline: Generic pipeline tools and implementation with an abstract type and default setting
• RtwithoutRenewalPipeline: Anything specific that we don't want as part of the abstract type (like plotting which probably don't want in the main to be truly generic?

[SamuelBrand1]

We would want the default to depend on a abstract type right with a specific implementation for our analysis so that others could easily branch off our defaults?

To make this truly generic it would suggest two modules:

• EpiAwarePipeline: Generic pipeline tools and implementation with an abstract type and default setting
• RtwithoutRenewalPipeline: Anything specific that we don't want as part of the abstract type (like plotting which probably don't want in the main to be truly generic?

I'm pro this idea; but implemented as a dispatch on something like make_pipeline rather than as a module (unless you meant module in the generic language sense?)

[seabbs]

I agree it should be a dispatch for the generic EpiAwarePipeline.

I meant that you would have another module (in the package sense) that would contain the concrete type, any custom methods, and just that is not generic like plotting for the specific examples?

[SamuelBrand1]

Gotcha.