# Discussion: Context Dispatch - yes? no? questions? answers?

**URL:** <https://discourse.julialang.org/t/discussion-context-dispatch-yes-no-questions-answers/24194>\
**Category:** Internals & Design\
**Created:** [May 14, 2019, 6:04am UTC](https://discourse.julialang.org/t/discussion-context-dispatch-yes-no-questions-answers/24194 "2019-05-14T06:04:01Z")\
**Posts on this page:** 1\
**Showing post:** 12

<div class="post-metadata">

**Author:** ![chakravala](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chakravala/32/6832_2.png) [@chakravala](https://discourse.julialang.org/u/chakravala)\
**Post date:** [May 17, 2019, 4:20am UTC](https://discourse.julialang.org/t/discussion-context-dispatch-yes-no-questions-answers/24194/12 "2019-05-17T04:20:33Z")

</div>

> [@TsurHerman](#):
>
> > [@StefanKarpinski](#):
> >
> > What if module `A` instead defined
> > 
> > ```julia
> > isless(x, y) = "surprise!"
> > 
> > ```
> > 
> > This seems like it would cause `sort!` to fail with a method error even though the two `isless` functions are not the same generic function and Base is not trying to call the one that `A` defines or exports.
> 
> Ah, very interesting, that is not directly relevant to Context Dispatch but to the complementary idea -Automatic Merging of Exported Functions.  
> And in that case you should get a Method Error: ambiguous just like you would get now.

This is an issue that was already discussed before, in terms of the `SharedFunctions` discussion

> [@Proposal for SharedFunctions.jl package for optional dependency management](https://discourse.julialang.org/t/proposal-for-sharedfunctions-jl-package-for-optional-dependency-management/23526/28):
>
> A different generic function with the same name is a function with the same name as another function… For example:
> 
> ```julia
> module A
> f(x) = x
> end
> 
> module B
> f(x, y) = x + y
> end
> 
> ```
> 
> Here `A.f` and `B.f` are different (generic) functions.
> 
> The reason why we cannot just merge the two `f` is because of how you write generic code.

> [@Proposal for SharedFunctions.jl package for optional dependency management](https://discourse.julialang.org/t/proposal-for-sharedfunctions-jl-package-for-optional-dependency-management/23526/31):
>
> How about this rule to solve this: Only import a name from a SharedFunctions package if you don’t intend to write generic method with only the Any type dispatch; otherwise have the generic definitions in SharedFunctions Shared function names with completely generic method definitions should either have the generic definitions in the SharedFunctions package not be imported from SharedFunctions This way, if there is a need for generic methods, the fully generic method is either shared by al…

> [@Proposal for SharedFunctions.jl package for optional dependency management](https://discourse.julialang.org/t/proposal-for-sharedfunctions-jl-package-for-optional-dependency-management/23526/34):
>
> In theory we could almost make it automatic, right? That is, have a github bot that generates a PR that extracts all exported function names, abstract types and abstract docstrings into an abstract header package, and rewires the old package to require and import and extend and reexport functions from the abstract header package. In theory, the creation of lightweight AbstractFoo / HeaderFoo packages from some Foo package should not requite a lot of human thought or intervention (corner case: …

---

_[View the full topic](https://discourse.julialang.org/t/discussion-context-dispatch-yes-no-questions-answers/24194)._