Re: [julia-users] Preferred way to structure a module

[Mauro]

 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

Re: [julia-users] Preferred way to structure a module

[colintbowers]

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 

[julia-users] Preferred way to structure a module

[colintbowers]

Hi all,

I'm just writing with a broad question about how to structure a module in 
Julia.

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. 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. A second strategy 
would be the SmoothingKernels package which appears to have a different 
function name for each kernel.

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