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 >> > >> > >> >>
