If the functions were merged in some way it would be confusing no matter how you do it. I hope these two formulations give meaning to you.
The problem with requiring functions to have disjoint argument types, is that that a module might add method definitions in an update. Then YOUR code breaks, because the modules does not satisfy the requirement for merging functions anymore. This could also be caused by changing inheritance trees and Union definition changes, and if multiple inheritance gets implemented that might complicate the issue even more. If you merge all functions, you suddenly have a problem when a function call suddenly dispatches to the function in another module. YOUR code will again break, without any indication as to what happened. Ivar kl. 19:37:05 UTC+1 søndag 12. januar 2014 skrev Freddy Snijder følgende: > > Hi Ivar, > > Thanks for your explanation. Please refer to my earlier response to John, > I understand now that I have to make the provenance clear, but still I was > wondering if it is really necessary. Your feedback is appreciated. > > Cheers, > > Freddy > > On Sunday, January 12, 2014 7:13:03 PM UTC+1, Ivar Nesje wrote: >> >> To add a more elaborate explanation on why your proposed behavior would >> be even more confusing than the current behavior. >> >> module A >> export my_parse >> my_parse(s::String) = "ParsedA: " * s >> >> end >> >> module B >> export my_parse >> my_parse(s::ASCIIString) = parse_int(s,32) >> end >> >> The trouble here is that A and B are different namespaces and give a >> different meaning to the my_parse function. One has a more specific >> signature than the other, but that does not mean that they can be >> interchanged, and neither the user who pull two modules together nor the >> independent developers of A and B know that this conflict will cause >> strange and erroneous behavior. >> >> The behavior you see now is probably going to change when >> https://github.com/JuliaLang/julia/issues/4345 get resolved. >> >> >> >> >> kl. 18:57:08 UTC+1 søndag 12. januar 2014 skrev John Myles White følgende: >>> >>> Freddy, >>> >>> This is definitely one of the more confusing things about Julia, but >>> it’s the best current solution anyone has proposed. >>> >>> The problem with your example is that methods can only be extended to >>> work on new types if you make their provenance clear. In your example, you >>> would do something like the following: >>> >>> module A >>> export f >>> f(s::String) = "Some operation with a String"; >>> end >>> module B >>> A.f(b::Bool) = "Some operation with a boolean"; >>> end >>> >>> Absent an explicit qualification of the origin of the “f” name in module >>> B, Julia assumes that the f method in B is totally unrelated, which >>> effectively overwrites the f method in A. >>> >>> — John >>> >>> On Jan 12, 2014, at 9:48 AM, Freddy Snijder <[email protected]> >>> wrote: >>> >>> > Hello Julia Users, >>> > >>> > I'm new to Julia and came across some behaviour of Julia, related to >>> methods, I didn't expect. >>> > >>> > Case A) In the REPL, when I define two methods, I get the behaviour I >>> expect: >>> > >>> > julia> f(s::String) = "Some operation with a String"; >>> > julia> f(b::Bool) = "Some operation with a boolean"; >>> > julia> f >>> > f (generic function with 2 methods) >>> > So far, so good. >>> > >>> > Case B) Now if I have a file with this code and load it in to a fresh >>> REPL session (using 'include'): >>> > >>> > module A >>> > export f >>> > f(s::String) = "Some operation with a String"; >>> > end >>> > module B >>> > export f >>> > f(b::Bool) = "Some operation with a boolean"; >>> > end >>> > then, when stating 'using A' and 'using B', I get a warning that >>> there is a conflict with an existing f: >>> > >>> > julia> using A >>> > julia> f >>> > f (generic function with 1 method) >>> > julia> using B >>> > Warning: using B.f in module Main conflicts with an existing >>> identifier. >>> > julia> f >>> > f (generic function with 1 method) >>> > I would have expected that Julia would see this as the same method >>> with two different argument definitions, just like in Case A). >>> > I have multiple modules that define the same methods for different >>> composite types, which seems a normal way of working to me. >>> > >>> > What am I doing wrong? The way Julia currently handles this seems >>> incorrect to me ... >>> > >>> > I'm interested to hear your input! >>> > >>> > Kind regards, >>> > >>> > Freddy >>> > >>> > PS : I'm on Julia Version 0.3.0-prerelease+584 (2013-12-19 22:26 UTC), >>> Commit 06458fa* (2 days old master), x86_64-apple-darwin13.0.0 >>> > >>> > >>> >>>
