Thanks, David! Requiring StatsBase and importing StatsBase.fit! fixes the problem.
Of course that doesn't prevent other authors from writing other packages I don't know about with overlapping names. But I take it from previous posts on this thread that on 0.4 `using` multiple modules that export the same function results in an error rather than a silent overwrite; which is at least easier to debug. On Thu, Aug 6, 2015 at 6:28 PM, David Gold <david.gol...@gmail.com> wrote: > One thing I believe you could do is actually require StatsBase for > LowRankModels and extend StatsBase.fit! in your LowRankModels module. As > long as there are no method signature conflicts, I think this should work > fine (although you might end up with some new ambiguity warnings to deal > with). > > Ideally such a generic verb as `fit!` would be defined in a package even > more generic than StatsBase, like ModelBase or something, and both > StatsBase and LowRankModels (as well as any other package that uses the > verb in a similar spirit) would require ModelBase (or whatever) and extend > `ModelBase.fit!`. > > > On Thursday, August 6, 2015 at 6:23:14 PM UTC-7, David Gold wrote: >> >> Madeleine, >> >> You are experiencing these problems in 0.3, correct? >> >> On Thursday, August 6, 2015 at 3:46:49 PM UTC-7, Madeleine Udell wrote: >>> >>> I've been running into major user problems because of the silent >>> overwriting of functions from one module by functions from another. My >>> LowRankModels module interacts closely with the DataFrames module, which >>> imports a bunch of stuff from StatsBase. Internally, I'm careful to use >>> `import` rather than `using`; but users often want to do `using >>> LowRankModels, DataFrames`. Depending on the order of the using statements, >>> either the LowRankModels.fit!(g::GLRM) function is overwritten, or the >>> StatsBase.fit!(obj::StatisticalModel) function is. This is *extremely* >>> confusing for users... >>> >>> On the other hand, I *like* the fact that I'm reusing the name `fit!`, >>> since the (semantic) sense in which LowRankModels fits a GLRM is similar to >>> the sense in which StatsBase fits statistical models, and so I *don't* want >>> to change the name... >>> >>> What's a good solution? >>> >>> On Thursday, April 30, 2015 at 2:26:19 PM UTC-7, Scott Jones wrote: >>> >>> Maybe because it seems that a lot of the major packages have been put >>> into Base, so it isn't a problem, as MA Laforge pointed out, leading to >>> Base being incredibly large, >>> with stuff that means Julia's MIT license doesn't mean all that much, >>> because it includes GPL code by default... >>> >>> Scott >>> >>> On Thursday, April 30, 2015 at 5:03:52 PM UTC-4, Stefan Karpinski wrote: >>> >>> On Wed, Apr 29, 2015 at 9:08 PM, Scott Jones <scott.pa...@gmail.com> >>> wrote: >>> >>> Your restrictions are making it very hard to develop easy to use APIs >>> that make sense for the people using them… >>> >>> That’s why so many people have been bringing this issue up… >>> >>> >>> Not a single person who maintains a major Julia package has complained >>> about this. Which doesn't mean that there can't possibly be an issue here, >>> but it seems to strongly suggest that this is one of those concerns that >>> initially appears dire, when coming from a particular programming >>> background, but which dissipates once one acclimatizes to the multiple >>> dispatch mindset – in particular the idea that "one generic function" = >>> "one verb concept". >>> >>> ... >>> >>> ... >> >> -- Madeleine Udell Postdoctoral Fellow at the Center for the Mathematics of Information California Institute of Technology www.stanford.edu/~udell (415) 729-4115
