I believe the reason fit! and similar names are defined in StatsBase is so that there would be one canonical version of the name the everyone can import and extend.
On Friday, August 7, 2015 at 5:03:00 AM UTC+3, Madeleine Udell wrote: > > 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 <[email protected] > <javascript:>> 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 <[email protected]> > 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 > ...
