That's a good approach if you're going to dispatch on the types, but if they're just values, we really should have something more like an enum. At this point, I'm thinking that @enum and @flags are good macros to have – where the @enum macro just defaults to 0, 1, 2, etc. while @flags defaults to 1, 2, 4, 8, etc. and defines bitwise operations on the flag values.
On Thu, Dec 26, 2013 at 8:13 AM, andrew cooke <[email protected]> wrote: > great, thanks. a concrete example is just what i needed. andrew > > > On Thursday, 26 December 2013 00:06:07 UTC-3, Kevin Squire wrote: > >> The julia sort code might provide some guidance. It follows your last >> proposal, having an abstract type Algorithm, and a number of concrete, >> empty Algorithm subtypes (QuickSort, MergeSort, etc.), plus exactly one >> global constant instance of each of these subtypes. So, as you suggested, >> there is a little bit of setup overhead, but it allows you to use the >> "value" of the global constants for dispatch. >> >> Kevin >> >> >> On Wed, Dec 25, 2013 at 4:45 PM, andrew cooke <[email protected]> wrote: >> >>> I want to parametrize some code, so that it does one of three different >>> things, depending on the "value" of a parameter. The parameter is purely >>> symbolic - there's no corresponding numerical value. >>> >>> There's an enum.jl in examples and also some discussion of related ideas >>> in issues. But this isn't (yet) in the language, and anyway it seems crude >>> (these are symbols, not numbers). >>> >>> There's also the possibility of using an abstract type and then three >>> concrete subtypes. That seems like too much work but, as far as I can >>> tell, is the way to "do" algebraic types in Julia (see list.jl example). >>> >>> I guess I am overthinking this. But what is the right approach? >>> >>> Thanks, Andrew >>> >> >>
