Actually, this is something I used to do way back in Fortran 77 with COMMON blocks and frequently used PARAMETER statements, before modules were introduced in Fortran 90. There may be a better way with Julia, perhaps others more proficient in Julia can comment.
--Peter On Wednesday, February 26, 2014 7:40:43 AM UTC-8, Robert Feldt wrote: > > Wow, that's an interesting idea. Will explore. Is this something that > you/people frequently use in Julia? Not something I've seen much in other > languages. Is there some downside? I imagine it is hard to directly test > the common code or one includes it into a dummy type for testing purposes? > > Cheers, > > Robert > > Den onsdagen den 26:e februari 2014 kl. 14:41:45 UTC+1 skrev Peter Simon: >> >> How about using 4., but instead of copying redundant data/fields into >> each variant, put this common material into a small file and "include" it >> in each of the variants? Then only a single version needs to be edited and >> maintained. >> >> --Peter >> >> P.S. BlackBoxOptim is a great contribution. I plan to make heavy use of >> it in the near future in designing hardware. >> >> On Tuesday, February 25, 2014 10:44:46 PM UTC-8, Robert Feldt wrote: >>> >>> I really like Julia's dispatch mechanisms, type system and so on. I have >>> found a number of different ways I use it to design libraries and programs. >>> But it would be great with some patterns/ideas/feedback from more seasoned >>> Julia programmers. What are your Julia Design Patterns? >>> >>> A concrete situation that I have struggled somewhat with is how to best >>> design in Julia for the situation where I have one main/default >>> algorithms/set-of-behaviors+data but then with a multitude of small >>> variations. Typically there is a large set of data and methods/functions >>> that are the same for the whole class of things and there are only 1-4 >>> functions/methods that need to change for each variation. An example from >>> BlackBoxOptim ( https://github.com/robertfeldt/BlackBoxOptim.jl ) is >>> where there is one type for DifferentialEvolution and then multiple >>> different variants of DE where only 1-2 functions differ from the "base" DE >>> one. >>> >>> I have found a few different "design patterns" for this situation but >>> not sure what is the long-term best: >>> >>> 1. Have a few Function fields in the "base" (composite) type which are >>> set up at construction time and that implements the variant-specific >>> behaviors. This is simple and direct but feels a bit "un-Julia" since it >>> does not really use the dispatch system. One also has to predict the >>> variation points (here: function) upfront which might not be flexible >>> enough. Also performance might suffer since the types of the function not >>> known. >>> >>> 2. Have one XBase type which includes a field of an abstract XStrategy >>> type where specific sub-types to XStrategy implements each variant by >>> implementing variant-specific functionality. This seems fairly efficient, >>> but again one has to predict more or less where the variations should >>> happen since the functions on the XBase type need to call to the XStrategy >>> functions. >>> >>> 3. Have one XBase type which is then included as a field in specific >>> variants. This seems efficient and flexible but the code is somewhat >>> cluttered in that one has to have one extra indirection when accessing >>> common data/fields (this is a similar problem in 2 above though). >>> >>> 4. "Copy" the common data/fields of XBase into each specific variant. >>> This is the most flexible and should have high performance but there seem >>> to be a risk that bugs have to be changed in multile source code locations >>> since it is a kind of "copy-paste reuse". >>> >>> Would be great to hear your advice/feedback on how you design in/with >>> the Julia type and dispatch system. >>> >>> Thanks, >>> >>> Robert Feldt >>> >>
