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

Reply via email to