How about making a type for your solver methods like so
immutable Method{Name}
para1::Int
para2::Float64
...
end
method_a = Method{:A}(p1, p2, ...)
method_b = Method{:B}(p1, p2, ...)
# Then the solve function could be
function solve(data::DataFrame, method::Method{:A})
# common setup
out = setup(data)
# solve for method A
...
# common finish
out = finish(out)
end
function solve(data::DataFrame, method::Method{:B})
# common setup
out = setup(data)
# solve for method B
...
# common finish
out = finish(out)
end
If your Methods do not need any data, just make a type without any
fields
immutable Method{Name} end
method_a = Method{:A}()
method_b = Method{:B}()
PS: Style tip: functions and variables are in lower case by convention.
Types are capitalised.
On Fri, 2014-12-26 at 11:10, Oliver Pewter <[email protected]> wrote:
> Hello,
> I have a function, Solve(Data::DataFrame, Method::String), where I do some
> math operations on Data, but these operations are vastly different for each
> Method. I call one function, Solve, because I don't want to obfuscate my
> code when I'm calling this.
>
> So that leaves me with sorting out the code within Solve(). The way it's
> done currently is
>
> function Solve(...)
> # prep stuff, common to all methods
>
> if Method == "MethodA"
> # long piece of code
>
> else if Method == "MethodB"
> # another long piece of code
>
> # [five other methods]
>
> end
>
>
> # finish and return stuff
> end
>
> My question is then what's the best way to organise the code? I could
>
> 1. Include an external file instead of each [long piece of code] bit.
> Doesn't seem very clean.
> 2. Have functions MethodA(), MethodB() etc. and call them in each if/elseif
> statement
> 3. Have the functions from #2 and use some sort of eval/call or something
> instead of the whole if-else bit. So just call the right function based on
> the argument Method.
> 4. Have separate and completely self contained functions MethodA, MethodB
> etc. and call them directly from the code where I call Solve(). This is not
> ideal since the method is contained in the Method string and I'd have to do
> all the if-else charade every time.
>
> The reason the thread is called 'multiple dispatch on values' is because
> the ideal way, for me, would be to have something like
> Solve(Data::DataFrame, Method::MethodA), Solve(Data::DataFrame,
> Method::MethodB) etc. (where MethodA and MethodB are values, not types) So
> I could have separate methods for my solution, wouldn't worry about all the
> if-else mess.
>
> So my code works just fine, I'm just asking about best practice tips. Sorry
> if the description above is unclear.
>
> Thanks,
> Oli