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, kevin.dale.sm...@gmail.com 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.
