There is another option, which won’t necessarily work for plot but might resolve many other issues (and is frequently used on functions like push!): make both modules import a common function to extend.
What took me a while to understand in this context, is the distinction between a *function* and a *method* - Julia is one of very few contexts I’ve come across where the difference between these two actually makes a big difference. To brush up: - A *function* is a first-class citizen in the language. It has a qualified name (e.g. Gadfly.plot) and can, if imported, be referred to via the last part of the qualified name, which I will call the “short name” (e.g. plot). There can be many functions with the same short name, as long as they’re defined in different modules. - A *method* is (simplifying a bit) a function and a tuple of types. The function is basically just a way to group methods doing similar things, and the type tuple is what decides what code is run (multiple dispatch). One function can have many methods, but a method can only belong to one function. Additionally, no two methods belonging to the same function can have the same argument types. When you say function dostuff() ... end in your code, what you’re *really* saying is this: If there is a *function* dostuff in the current context, extend it with a *method* that takes the arguments of the following types: (). If there is *no* such function, define one for me and then add the method. The confusing thing when doing using Gadfly and using Gtk (in some order) is that since there isn’t a function Base.plot for them to import, they must both define their own. And even though the two plot methods have the same short name, they’re really not the same function, and so their methods have nothing to do with eachother. (The fact that we associate them with each other is just because they happen to have the same short name, which only really matters to us humans reading the code anyway…) Thus, to make it possible for several modules to extend the same function with new methods, *the function must be defined outside all of the modules*, so they can all import it and extend it, rather than define a new one. As mentioned above, many packages import e.g. Base.push! to be able to add methods to it, and since they all extend Base.push! rather than defining their own methods, the order in which you use them (with using) doesn’t matter (at least as long as they don’t have any argument type conflicts). Personally, I think it’s a *good* thing that Julia doesn’t do too much magic stuff in situations like this. Plotting is something where the API will look quite similar regardless of which package you’re using, and it would be hopeless to try to merge the plot functions from e.g. PyPlot and Winston… // T On Wednesday, July 23, 2014 3:06:03 PM UTC+2, Andreas Lobinger wrote: Hello collague, > > On Tuesday, July 22, 2014 4:25:46 PM UTC+2, Mauro wrote: >> >> > I agree that there should be some means of resolving conflicts (by >> warning, >> > by precedence) but just dropping a whole set of methods because they >> > conincidentially have the same name AND at the same time advertising >> > multiple dispatch in julia doesn't fit for me. >> >> Multiple dispatch would still work and no methods are dropped, you would >> just need to fully qualify the generic function, like >> e.g. `Gadfly.plot`, or you could do `plot = Gadfly.plot` to get the one >> generic function you want into the global namespace. I think this would >> be less confusing than the order of `using` be significant. >> > > In principle i agree, everything that is defined in the Modules is usable > regarding its own namespace. But then, why do we have the export of > functions? It's not even needed... > If you strictly prefix all functions by their module everything will be > alright, but what in mixed environments? > > The point i'm trying to make is: The current situation - not merging the > functions/methods - creates a dependency between Modules/Packages. Is this > the intended work style? > >
