> I would argue that this would be prohibited by the compiler as it could not > distinguish between > foo(x::Number) = 2 > and > foo(x::Float64) = 3
Yes it can: julia> foo(x::Number)=1 foo (generic function with 1 method) julia> foo(x::Float64)=2 foo (generic function with 2 methods) julia> foo(5) 1 julia> foo(5.) 2 > In the example I gave, count was allowed to be exported from my two modules > just by being defined by Base. Yet the two count's have different meanings > from each other and from the Base.count. On the other hand steadystate() > was not merged even though the end-result is the SAME: one would have two > methods that work on different types of arguments and do different things. I don't think it is good practice to add unrelated methods to generic functions in Base. A guide-line could be to check whether your methods matches up with the help text, if so, add it to Base.count otherwise not. If not, either give it a different name or do not export it, so the user has to fully qualify it MyMod.count. This is just my opinion but I suspect at least some share it.
