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 >> >
