Just wanted to say thanks for responding, and if you do encounter that
thread again in your travels, I'd be very grateful if you could post a link
(but please don't waste time searching for it on my behalf).
Cheers,
Colin
On Monday, 18 May 2015 18:22:06 UTC+10, Mauro wrote:
>
> > For my own modules, I've tended to follow the example of the
> Distributions
> > and Distances package, where each distribution (or distance) is its own
> > type, and then there is a small number of generic functions (eg
> "evaluate")
> > that use multiple dispatch to return the appropriate value depending on
> the
> > input type.
>
> If I recall correctly, recent discussions on this list suggest that many
> (but not all) see this as the most julian pattern. I think it may have
> been discussed within one of those recent super-long threads.
>
> > But I've seen source code in other packages that indicates a different
> > strategy. For example, the Optim package appears (and please correct
> > me if I'm wrong - I'm definitely not an expert) to have a different
> > Symbol for each optimisation algorithm, and then uses if elseif
> > statements to ensure the right optimisation procedure is called.
>
> (Not having looked at the code) I would, instead of `:alg_a` use
> `AlgTyp{:a}` and dispatch on it, i.e. the method described above.
>
> > A second strategy would be the SmoothingKernels package which appears
> > to have a different function name for each kernel.
>
> This might be fine too. However, to write generic code one has to
> resort to higher order functions which are not so performant at the
> moment.
>
> > So my question: Is there a preferred "julian" way of doing things, or is
> it
> > a case of whatever seems to be the best fit on a case-by-case basis?
> >
> > Cheers,
> >
> > Colin
>
>
