>From a user point of view, if you mix and match very different packages, which may have or maybe will have name clashes in the future, you may want to consider to just import them and not 'using' them. And then fully qualify your functions. This is probably the prudent thing to do for larger code-bases. However, the using is quite nice as it reduces verbosity.
On Tue, 2015-01-13 at 20:56, Petr Krysl <[email protected]> wrote: > I realized that one reason the discussion at > https://github.com/JuliaLang/julia/issues/4345 > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FJuliaLang%2Fjulia%2Fissues%2F4345&sa=D&sntz=1&usg=AFQjCNEVGpsg9UKLmRUDr3BN281cKXgCKA> > was > not addressing my viewpoint was that there the issue is methods that > implement the SAME concept embodied by a given generic function. > > What I would like to see addressed are DIFFERENT concepts addressed by a > function name. There was just a discussion like this here: > https://groups.google.com/forum/?fromgroups=#!topic/julia-users/CejvtDWUIjk > > For instance, take PDEs: a number of PDEs are "steady-state" (Poisson, > Helmholtz, harmonic vibration, ...). The solver may be quite reasonably > called "steadystate()". The logic will be certainly very different inside > each solver, and the argument to the solver would also indicate that > > steadystate(p::Poisson) > steadystate(p::Helmholtz) > steadystate(p::HarmonicVib) > > An economics package might also wish to export a name like this. Even if we > were to argue that somehow the above are similar, there are certainly > legitimate uses for function names meaning very different things. > > Should this be disallowed as suggested in > https://github.com/JuliaLang/julia/issues/4345 > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FJuliaLang%2Fjulia%2Fissues%2F4345&sa=D&sntz=1&usg=AFQjCNEVGpsg9UKLmRUDr3BN281cKXgCKA> > ? > > It seems to me that situations like this might only lead to trouble if the > compiler encounters an ambiguous choice as to which function to call, no? > Such as when there are two functions f() (no arguments), the compiler > cannot possibly know which is intended and such a double definition should > not be allowed. > > P > > On Monday, January 12, 2015 at 11:24:07 PM UTC-8, Ivar Nesje wrote: >> >> New method definitions will replace the previous definition. >> >> If you put the function in a module and bring them into you scope with >> using/importall, you'll run into >> https://github.com/JuliaLang/julia/issues/4345 >> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FJuliaLang%2Fjulia%2Fissues%2F4345&sa=D&sntz=1&usg=AFQjCNEVGpsg9UKLmRUDr3BN281cKXgCKA>, >> >> which can be considered either a bug or a missing feature.
