On Saturday, April 25, 2015 at 12:55:39 PM UTC+10, Michael Francis wrote: > > the resolution of that issue seems odd - If I have two completely > unrelated libraries. Say DataFrames and one of my own. I export value( > ::MyType) I'm happily using it. Some time later I Pkg.update(), unbeknownst > to me the DataFrames dev team have added an export of value( ::DataFrame, > ...) suddenly all my code which imports both breaks and I have to go > through the entire stack qualifying the calls, as do other users of my > module? That doesn't seem right, there is no ambiguity I can see and the > multiple dispatch should continue to work correctly. > > Fundamentally I want the two value() functions to collapse and not have to > qualify them. If there is a dispatch ambiguity then game over, but if there > isn't I don't see any advantage (and lots of negatives) to preventing the > import. > > I'd argue the same is true with overloading methods in Base. Why would we > locally mask get if there is no dispatch ambiguity even if I don't > importall Base. > > Qualifying names seems like an anti pattern in a multiple dispatch world. > Except for those edge cases where there is an ambiguity of dispatch. > > Am I missing something? Perhaps I don't understand multiple dispatch well > enough?
IIUC the problem is not where you have two distinct and totally separate types to dispatch on, its when one module also defines methods on a common parent type (think about ::Any). That module is expecting the concrete types it defines methods for to dispatch to these methods and all other types to dispatch to the method defined for the abstract parent type. But if methods from another module were combined then that behaviour would be changed silently for some types to dispatch to the second modules methods. But nothing says these two functions do the same thing, just because they have the same name. The example I usually use is that the `bark()` function from the `Tree` module is likely to be different to the `bark()` function in the `Dog` module. So if functions are combined on name, mixing modules can silently change behaviour of existing code, and thats "not a good thing". To extend an existing function in another module you can explicitly do so, ie name Module1.funct() so that the behaviour of the function can be extended by methods for other types, but by explicitly naming the function, you are guaranteeing that the methods have acceptable semantics to combine.
