Refactor with method hierarchy

[seabbs]

This is a draft PR that implements an alternative workflow (building on that discussed in #75) which uses multiple dispatch to allow use of both a struct and a function that takes arguments.

Implementation:

https://github.com/CDCgov/Rt-without-renewal/blob/refactor-struct-to-arg/EpiAware/src/latent-processes.jl

See example use:

priors = default_rw_priors()
n = 10  # Number of steps in the random walk

# Directly using the tag-based dispatch
latent_rw = latent_process(RandomWalkLatentProcessArg(), n, var_prior = truncated(Normal(0.0, 0.05), 0.0, Inf),
	init_prior = Normal())

# Create a RandomWalkLatentProcess instance with priors
rw_lp = RandomWalkLatentProcess(priors[:init_rw_value_prior], priors[:var_RW_prior])

# Using the struct-based dispatch
latent_rw_struct = latent_process(rw_lp, n)

# Attempting to call with a generic AbstractLatentProcess
latent_process(AbstractLatentProcess(), n)

# Attempting to call with a generic AbstractLatentProcessArg
latent_process(AbstractLatentProcessArg(), n)

Con

• Adds an additional method that needs to be defined
• May not be a standard approach
• Leads to a slightly more complex stack trace
• Has no code impact for our use case

Plus

• Can document the arguments in the funciton docs and then link out to the struct that carries them
• May make resuse of low level functions easier
• Increases code modularity (?)

[SamuelBrand1]

I think defining a type hierarchy for the underlying priors and an auxiliary type hierarchy that is initimately connected to it is overkill.

For example, you can dispatch on the type of the first type without using it if you want to.

[SamuelBrand1]

It feels like the point of the above is to lower down to this function; but you can get the same effect by specifying the fields of RandomWalkLatentProcess (i.e. not using a NamedTuple or Dict of priors of potentially any name) and dispatching on that.

I'd avoid that by having RandomWalkLatentProcess have determined typed fields and saving a bunch of code repetition.

[SamuelBrand1]

Its a pretty standard pattern to pass structs and dispatch on type information in Julia Packages; which I think you are trying hard to avoid here?

For example, in DifferentialEquations.jl a workflow might be:

1. create a DEProblem struct (with different behaviours being ODEProblem, SDEProblem etc.
2. Choose a solution method struct, e.g. Tsit5
3. pass the above to solve e.g. solve(prob; Tsit5()) along with any other key words.

For example, scraping an example from here

function lorenz!(du, u, p, t)
    du[1] = 10.0 * (u[2] - u[1])
    du[2] = u[1] * (28.0 - u[3]) - u[2]
    du[3] = u[1] * u[2] - (8 / 3) * u[3]
    nothing
end

u0 = [1.0; 0.0; 0.0]
tspan = (0.0, 100.0)
prob = ODEProblem(lorenz!, u0, tspan)
solve(prob, Tsit5());

EDIT: even lowering right down to the time stepping we find functions with struct arguments e.g. here.