Hello Mauro, Thank you for your answer.
> 1. Use different function names: getitems, getitems_maxid. Not too > elegant > > as you mix purpose and details of function usage in its name. > > 2. Use named arguments. This will cause the function implementation to > grow > > (a series of if / else), again not too elegant. > > 3. Define a new type: ItemId which behaves exactly as Int but can be > used > > to 'activate' multiple dispatch (one function would use Int and the > second > > one would use ItemId). Generally not the best approach if you have > methods > > each having an argument that should be really represented as an Int > rather > > than a new type. > > For dispatch to work you have to use #3. By the same logic you use in > #1 this is good: a 3 of ItemId has different "units" to a 3 of > maxnumitems. For instance, you shouldn't be able to do ItemId + > maxnumitems. Using different types gives you that and is the most > Julian approach but #1 and #2 work fine and might be the right solution > at times too. The "units" explanation is very convincing. But what would you do when you have two methods that have different semantics but are indistinguishable by the argument types? A quick example: getitems( maxitemid::ItemId ) getitems( minitemid::ItemId ) both arguments use the same type and so no multiple dispatch is possible here (introducing two types here wouldn't be right I feel). I'm just thinking about general approach to structuring code in Julia, like when do you handle things with multiple dispatch and when do you switch over to another convention. > Note that a type such as > > immutable ItemId > id::Int > end > is as performant as an Int. Thanks. Would it be possible to define a new type which is not a composite type, just an Int without any fields but with its own name? So that you can use it like "a" rather than "a.id"? Thank you again, Krystian
