# Best practices for "base" packages to define common function names?

**URL:** https://discourse.julialang.org/t/best-practices-for-base-packages-to-define-common-function-names/70674
**Category:** General Usage
**Created:** [October 31, 2021, 2:24am UTC](https://discourse.julialang.org/t/best-practices-for-base-packages-to-define-common-function-names/70674 "2021-10-31T02:24:48Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![Alec\_Loudenback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/alec_loudenback/32/278_2.png) [@Alec\_Loudenback](https://discourse.julialang.org/u/Alec_Loudenback)
#### Post date: [October 31, 2021, 2:24am UTC](https://discourse.julialang.org/t/best-practices-for-base-packages-to-define-common-function-names/70674/1 "2021-10-31T02:24:48Z")

</div>

I have a couple of packages that have functions with the same name, but operate on different structs. Users could definitely have both packages loaded at the same time.

I think the best way to prevent issues from conflicting names is to pull the functions into a common “base” package? Are there good examples of this? Any best practices when setting up the base package and starting to extend those versions in the dependent packages?

---

<div class="post-metadata">

### Author: ![Henrique\_Becker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/henrique_becker/32/15443_2.png) [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)
#### Post date: [October 31, 2021, 3:04am UTC](https://discourse.julialang.org/t/best-practices-for-base-packages-to-define-common-function-names/70674/2 "2021-10-31T03:04:27Z")

</div>

Extending `Base` functions for structs you own is **not** type piracy and there may be good cases for doing it (`JuMP.jl` does it for `empty!` for example). However, some people believe that if you do that only to avoid conflicting names, and your function is not an specialization of the same idea as the `Base` function (but to your `struct` instead) then you should keep it in your module (i.e, define a brand new function) and maybe do not export it by default. The name given for the pattern of extending a `Base` function with unrelated methods just to avoid name conflicts is called `punning` (because you are making a `pun` by conflating different meanings of a word together), and you probably will find older threads in Discourse talking about it.

---

<div class="post-metadata">

### Author: ![gustaphe](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gustaphe/32/18174_2.png) [@gustaphe](https://discourse.julialang.org/u/gustaphe)
#### Post date: [October 31, 2021, 6:45am UTC](https://discourse.julialang.org/t/best-practices-for-base-packages-to-define-common-function-names/70674/3 "2021-10-31T06:45:02Z")

</div>

Your current setup sounds like how it’s supposed to be: you have different types in each package, and each of them defines methods of some common function for that type.

The reason you might want a \*Base package is of you want unrelated packages to be able to use the function, without knowing about any of the types (by pulling in a dependency for one of the more expensive packages).

Example:

```julia
#FruitBase.jl
module FruitBase
export Fruit, bite
abstract struct Fruit end
function bite(::Fruit) end
end

#Apples.jl
module Apples
using FruitBase
import FruitBase.bite
export Apple
__init__ () = sleep(60) # this package is expensive to include
struct Apple <: Fruit end
bite(::Apple) = "cronch"
end

#Mooses.jl #meese?
module Mooses
using FruitBase # way cheaper than, for instance, Apples
export eat
eat(x::Fruit) = for _ in 1:10; bite(x);end
end
```
