> This does bring up a question about writing methods though. What happens > if two completely unrelated packages define a function 'foobar' (that isn't > part of Base or any other Julia standard package) and someone tries to use > both packages? It seems like this couldn't work. You would only get one > or the other, but whichever one was loaded last would always shadow the > other.
You need to fully qualify one of them (or better both) A.foo() B.foo() I think it will also print a warning when using the second package. > On Sunday, March 29, 2015 at 9:45:10 AM UTC-5, Milan Bouchet-Valat wrote: >> >> Le dimanche 29 mars 2015 à 09:33 -0400, Stefan Karpinski a écrit : >> >> Why is it odd? >> >> I understand that this behavior can be confusing the first time you >> experience it. Since multiple dispatch is one of Julia strong points, I >> also expected at first that all methods with the same name would be merged >> together, and that which one to call would be decided based on the >> signature. >> >> This expectation is of course problematic since it would mean that any >> module could override a private method used in another module. And I think >> the fact that unexported functions remain private to a module is quite >> natural and not surprising at all. >> >> The confusion arises when one "sees" (via using) a function (e.g. f) >> exported from another module, but writing >> f() = something >> does not extend it by default. Again, this is perfectly reasonable, since >> otherwise adding a new exported function in a module could suddenly >> override one which existed in a module that used it. >> >> But the downside of this is that two modules which define each its own >> version of f with non-conflicting signatures (e.g. f(::MyType1) and >> f(::MyType2)) cannot be used at the same time even though their >> interaction is perfectly OK, unless one imports f from the other, or both >> import it from a third module. This is very powerful to encourage >> coordination between packages, but it in some cases it can be annoying (and >> certainly surprising when coming from R -- which is not necessarily bad). >> In the present case, it means you have to depend on DataFrames, which is >> a big dependency if your package implements a replacement for it and does >> not call its code at all; or move function definitions to an >> AbstractDataFrames package. Maybe the latter is a good idea, and with >> explicit definitions of interfaces/traits it could be a good practice >> anyway. >> >> I'm not sure anything can be done to make this easier to grasp for >> newcomers. Could a warning could be printed when a module exports a >> function with the same name as a function exported from one of the modules >> it calls using on? This would most likely indicate a mistake, or an >> uncoordinated change in the reverse dependency. >> >> >> Regards >> >> On Mar 28, 2015, at 10:16 PM, [email protected] <javascript:> wrote: >> >> >> On Saturday, March 28, 2015 at 4:19:44 PM UTC-5, Mauro wrote: >> >> Now, generic functions carry >> around with them the module in which they were first defined. To extend >> such a function with another method in another module you either have to >> import it or fully qualify it (DataFrames.nrow). If you don't do that >> then you create a new generic function with the same name as the other >> but not sharing any methods. Also, this function will shadow the other >> one in the current module. >> >> >> >> Aha. This is the piece of information I was looking for. It seems a >> bit odd, but it does clear up some things. I'll have to play around with >> my implementation and this new information to see if it helps. >> >> >>
