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

Reply via email to