Wow, that's brilliant! I had no idea I could use parametrised types this
way.
At first I thought I'd call the solve function as
solve(data, Method{symbol("methodA")}())
but then I realised I could leverage multiple dispatch yet again and have
solve(data::DataFrame, method::String)
solve(data::DataFrame, method::Method{:A})
solve(data::DataFrame, method::Method{:B})
etc. with the first function converting the string to the Method type and
call the latter functions. I have to do some other prep stuff in the first
function anyway, so this is gonna be really convenient.
Thanks again and happy new year,
Oli
On Friday, December 26, 2014 10:34:31 AM UTC, Mauro wrote:
>
> 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 <oliver...@gmail.com
> <javascript:>> 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
>
>
