type hierarchy for projectors

[kczimm]

As discussed in #5, a functor API could be used to accommodate multiple implementations of a specific function like radon. I hope to use this issue to discuss possible type hierarchies. For example, I keep thinking of something like,

abstract type Beam end
struct PencilBeam <: Beam end
struct FiniteBeam <: Beam end

abstract type Driver end
struct RayDriven <: Driver end
struct PixelDriven <: Driver end

abstract type Projector{<:Beam,<:Driver} end

struct MyMethod{T<:AbstractRange,V<:AbstractRange} <:
       Projector{PencilBeam,RayDriven}
    detectors::T
    angles::V
end

function (m::MyMethod)(image::AbstractMatrix)
    sinogram = zeros(eltype(image), length(m.detectors), length(m.angles))

    # MyMethod algorithm

    sinogram
end

which I thought of after looking through Distributions.jl/common.jl. Other than just I think it looks nice, I can't see from the example above, where the usefulness of the types I setup is.

[johnnychen94]

Different algorithms have different parameters, and paramters might change over time (e.g., deprecations, improvements) and if you want to reuse the name radon, it would be clearer to extract those algorithm-specific parameters to the algorithm constructor rather than radon.

Well, it's like radon_alg1(img, args...), radon_alg2(img, another_args...), but conceptually,

alg = MyMethod(args...)
radon(img, alg)

looks better, and changing the API of MyMethod doesn't affect the general usage of radon.

[kczimm]

Sure, and so radon would look something like

radon(img, alg::T) where {T<:Projector} = (alg::T)(img)

?