# Function name conflict: ADL / function merging? **URL:** \ **Category:** Internals & Design\ **Tags:** proposal, namespaces\ **Created:** [April 14, 2018, 5:16pm UTC](https://discourse.julialang.org/t/function-name-conflict-adl-function-merging/10335 "2018-04-14T17:16:17Z")\ **Posts on this page:** 1\ **Showing post:** 92

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\ **Post date:** [April 17, 2018, 5:35pm UTC](https://discourse.julialang.org/t/function-name-conflict-adl-function-merging/10335/92 "2018-04-17T17:35:59Z")

This came up on slack recently, with respect to statistical `fit!` functions. This is an interesting case, because StatsBase.jl and OnlineStats.jl don’t really need to depend upon each other but both want to use the word `fit!` in compatible matter. At the same time, though, SkLearn.jl also defines its own `fit!`, but instead of using rows as its observations (like the former two packages do) it uses columns! Now in the first case, it seems obvious that the two methods could be merged. You can write your own code that calls `fit!` and doesn’t really care if you’re doing your stats immediately or incrementally. But if that third method gets merged, too, now suddenly you _do_ need to care that you’re not doing your stats via SkLearn or things will go sideways fast. There is a pain point here, but automatic method merging isn’t going to be the solution, nor is pushing everything into `Base`. Lots of words have been written about why those aren’t going to be the solution by many authors above. If you’re still not convinced, I encourage you to try re-reading those posts. For now there are those workarounds, and we may develop other alternatives in the future. --- _[View the full topic](https://discourse.julialang.org/t/function-name-conflict-adl-function-merging/10335)._