Example mode and unit tests for pipeline functions.

[SamuelBrand1]

Does as per title and closes #293

[SamuelBrand1]

I've moved the dispatch on being the example mode pipeline to the constructor for the list of configutations to loop over. Good shout @seabbs it is cleaner this way.

[seabbs]

See my comment. I thought the solution was just calling the abstract method internally to the new method and then calling rand on that?

[SamuelBrand1]

See my comment. I thought the solution was just calling the abstract method internally to the new method and then calling rand on that?

That was the original pass which I didn't like; I don't want to make a method which internally generates its internal abstract super type. To me that is weird.

for example:

abstract type MyAbstractType end
struct AType <: MyAbstractType
end


function foo(pipe::MyAbstractType)
 ...
 return list
end

function foo(pipe::AType)
 list = foo(get_super_type(pipe))
 return rand(list)
end

[seabbs]

What about having a DefaultEpiAwarePipeline that is just the abstract type fall backs and calling that? It just seems like a weird pattern (in the sense of forcing a lot of duplication)?

[seabbs]

Nice. Seems like a great solution.

[SamuelBrand1]

What about having a DefaultEpiAwarePipeline that is just the abstract type fall backs and calling that? It just seems like a weird pattern (in the sense of forcing a lot of duplication)?

I think a DefaultEpiAwarePipeline is tricky because we want to dispatch within the highest level method (highest level from p.o.v. of the type hierarchy).

What I've just pushed is the creation of an internal _selector method which does the selection from the list of possible scenarios (with default being to return all of them).

Going forwards I think the way we have done the pipe leans into trait-based programming (cf SimpleTraits.jl), but it was a bit of a leap to implement that in this PR.