Yes, I am struggling with this aspect as well and recently posed a related question (’Struggling with generic functions’) although slightly differently formulated.
John’s answer included below. In your example that might look like below update of the example I think. Like you (I think) I was looking to hide this from end users. Rob J. Goedman [email protected] module m1 export f f(x::ASCIIString) = println("ASCIIString: " * x) f{T<:String}(x::T) = println(" $(typeof(x)): " * x) f(x) = println(" $(typeof(x)): " * string(x)) end module m2 export f f(x::Int) = println("Int: " * string(x)) end import m1.f import m2.f f(7) f("Foo") f("\u2200 x \u2203 y") f(12.0) f(2.0+3.0im) On Dec 2, 2014, at 4:37 PM, John Myles White <[email protected]> wrote: There's no clean solution to this. In general, I'd argue that we should stop exporting so many names and encourage people to use qualified names much more often than we do right now. But for important abstractions, we can put them into StatsBase, which all stats packages should be derived from. -- John On Dec 2, 2014, at 4:34 PM, Rob J. Goedman <[email protected]> wrote: > I’ll try to give an example of my problem based on how I’ve seen it occur in > Stan.jl and Jags.jl. > > Both DataFrames.jl and Mamba.jl export describe(). Stan.jl relies on Mamba, > but neither Stan or Mamba need DataFrames. So DataFrames is not imported by > default. > > Recently someone used Stan and wanted to read in a .csv file and added > DataFrames to the using clause in the script, i.e. > > ``` > using Gadfly, Stan, Mamba, DataFrames > ``` > > After running a simulation, Mamba’s describe(::Mamba.Chains) could no longer > be found. > > I wonder if someone can point me in the right direction how best to solve > these kind of problems (for end users): > > 1. One way around it is to always qualify describe(), e.g. Mamba.describe(). > 2. Use isdefined(Main, :DataFrames) to upfront test for such a collision. > 3. Suggest to end users to import DataFrames and qualify e.g. > DataFrames.readtable(). > 4. ? > > Thanks and regards, > Rob J. Goedman > [email protected] <mailto:[email protected]> > On Dec 11, 2014, at 2:52 PM, samoconnor <[email protected]> wrote: > > Hi Rob, > > Ok, I see why that "works", but it's a different example. > > Assume that m1 and m2 are libraries from different vendors, they know nothing > about each other, but they both export methods for f(). > > It is surprising to me that importing two modules would cause one to > overwrite methods from the other with no warning or error. > > On Friday, December 12, 2014 9:45:37 AM UTC+11, Rob J Goedman wrote: > Sam, > > Maybe below slightly expanded version of your example will help. > > I think key is to import m1.f in module m2 > > Regards > Rob J. Goedman > [email protected] <javascript:> > > > module m1 > > export f > > f(x::ASCIIString) = println("ASCIIString: " * x) > f{T<:String}(x::T) = println(" $(typeof(x)): " * x) > f(x) = println(" $(typeof(x)): " * string(x)) > end > > > module m2 > > import m1.f > export f > > f(x::Int) = println("Int: " * string(x)) > end > > using m1 > using m2 > > f(7) > f("Foo") > f("\u2200 x \u2203 y") > f(12.0) > f(2.0+3.0im) > > > > >> On Dec 11, 2014, at 2:18 PM, samoconnor <[email protected] <javascript:>> >> wrote: >> >> The example below has two modules that define methods of function f for >> different parameter types. >> Both modules are imported. >> It seems like that "using" the second module causes the first one to >> disappear. >> Is that the intended behaviour? >> >> >> !/Applications/Julia-0.3.0-rc4.app/Contents/Resources/julia/bin/julia >> >> module m1 >> >> export f >> >> f(x::String) = println("String: " * x) >> f(x) = println(" ?: " * string(x)) >> end >> >> >> module m2 >> >> export f >> >> f(x::Int) = println(" Int: " * string(x)) >> end >> >> using m1 >> using m2 >> >> f(7) >> f("Foo") >> >> output: >> >> Int: 7 >> ERROR: `f` has no method matching f(::ASCIIString) >> >> >
