I'd vote for toivo's suggestion.
So this could be a design:
immutable Parser{Policy}
common
fields
end
#construction
parser = Parser{:policy1}(...)
#specialize the functions to a policy:
validmove(::Parser{:policy1}) = ...
validmove(::Parser{:policy2}) = ...
#define functions for all parsers
move!(::Parser) = ...
Am Freitag, 27. März 2015 05:39:36 UTC+1 schrieb Deniz Yuret:
>
> I've been wrecking my brain to figure out the best way to do this in
> Julia. We have a set of objects (parsers in my case), with common state
> elements and constructor (buffer, stack, a set of arcs etc.), but different
> move sets (arceager, archybrid etc. see this
> <http://anthology.aclweb.org/Q/Q13/Q13-1033.pdf> if interested). Thus
> functions like validmoves(), move!() etc. are of several different types.
> So far I have considered:
>
> 1. Just define multiple composite types with different move() methods
> (pro), listing the same fields and constructor for each (con).
>
> 2. Define a single "state" type that has the necessary fields and
> constructor (pro), include a "state" as a field in multiple composite types
> requiring double reference (con: i.e. you need to type parser.state.field
> instead of just parser.field).
>
> 3. Put the list of (common) fields in a file and include this file in the
> definition of each composite type. This prevents the problem of repeating
> the same code, but makes me a bit uneasy. It also does not solve the
> constructor problem (I guess I can put the body of the constructors in a
> common file and include it, but that makes me even more uneasy).
>
> 4. Have a single composite type with a field that indicates the "move
> policy". Then have functions like validmoves(), move!() etc. branch on
> this move policy. But that's just throwing away the beautiful function
> overloading machinery of Julia.
>
> Is there a "Julia" way that I am missing? Which strategy would you choose?
>
> best,
> deniz
>
>
