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