# Resolving name conflicts between my package and other, commonly used packages it does not depend on **URL:** \ **Category:** General Usage\ **Tags:** question, package\ **Created:** [May 29, 2024, 8:42pm UTC](https://discourse.julialang.org/t/resolving-name-conflicts-between-my-package-and-other-commonly-used-packages-it-does-not-depend-on/114937 "2024-05-29T20:42:21Z")\ **Posts on this page:** 6\ **Page:** 1

**Author:** ![brainandforce](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/brainandforce/32/211054_2.png) [@brainandforce](https://discourse.julialang.org/u/brainandforce)\ **Post date:** [May 29, 2024, 8:42pm UTC](https://discourse.julialang.org/t/resolving-name-conflicts-between-my-package-and-other-commonly-used-packages-it-does-not-depend-on/114937/1 "2024-05-29T20:42:21Z")

My package, [CliffordNumbers.jl](https://github.com/brainandforce/CliffordNumbers.jl), defines two functions: - `CliffordNumbers.similar_type(::Type{C}, ::Type{T}, ::Val{Q}) where {C<:AbstractCliffordNumber,T<:Union{Real,Complex},Q}` constructs a type similar to `C` but with type parameters `T` and `Q` in place of other type parameters of `C` (if they are present). - `CliffordNumbers.dot(x::AbstractCliffordNumber, y::AbstractCliffordNumber)` defines the dot product of two Clifford numbers. You might notice that these functions have very similar functionality to `StaticArrays.similar_type` and `LinearAlgebra.dot`, and you are correct! These operations, to my knowledge, have entirely compatible semantics. However, there’s a problem: CliffordNumbers.jl has no dependencies, not even LinearAlgebra, so exporting these names will conflict will cause name conflicts. For the moment, leaving `CliffordNumbers.dot` unexported is OK, as the left/right contractions are preferred to the dot product. However, I’d like to export `CliffordNumbers.similar_type` for the same reasons StaticArrays.jl does so. The question is: is there any way to define and export `CliffordNumbers.dot` and `CliffordNumbers.similar_type` that will not conflict with the definitions of `dot` and `similar_type` in their respective packages, **but also does not require me to take them as a hard dependency?** I am aware of [this topic](https://discourse.julialang.org/t/function-name-conflict-adl-function-merging/10335/205) which discusses the problem of function merging at length, but I’m wondering if this is any different now that package extensions are a thing (last reply was in 2018). The key issue here is that `CliffordNumbers.dot` and `CliffordNumbers.similar_type` should be usable _without loading either LinearAlgebra or StaticArrays_. ---

**Author:** ![abraemer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/abraemer/32/51403_2.png) [@abraemer](https://discourse.julialang.org/u/abraemer)\ **Post date:** [May 30, 2024, 4:44am UTC](https://discourse.julialang.org/t/resolving-name-conflicts-between-my-package-and-other-commonly-used-packages-it-does-not-depend-on/114937/2 "2024-05-30T04:44:33Z")

Depending on LinearAlgebra.jl is not a real dependency until it leaves the sysimg which might happen at some point. So for now, it would be fine imo to depend on that and just add your `dot` method to `LinearAlgebra.dot`. As for StaticArrays.jl, there is a really light-weight interface package called StaticArraysCore.jl which contains essentially no code and just defines the types and a couple of functions (but no methds thereof). You could maybe depend on that to add your `similar_type` methods to SA’s function. ---

**Author:** ![tecosaur](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tecosaur/32/23206_2.png) [@tecosaur](https://discourse.julialang.org/u/tecosaur)\ **Post date:** [May 30, 2024, 5:18am UTC](https://discourse.julialang.org/t/resolving-name-conflicts-between-my-package-and-other-commonly-used-packages-it-does-not-depend-on/114937/3 "2024-05-30T05:18:22Z")

I will say, when it comes to `dot` / `⋅`, I do think it would be nice if it was defined and exported by `Base`, and `LinearAlgebra` et al. just added methods to it. ---

Oh, and the same for `adjoint` / `'`. ---

**Author:** ![brainandforce](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/brainandforce/32/211054_2.png) [@brainandforce](https://discourse.julialang.org/u/brainandforce)\ **Post date:** [May 30, 2024, 5:55am UTC](https://discourse.julialang.org/t/resolving-name-conflicts-between-my-package-and-other-commonly-used-packages-it-does-not-depend-on/114937/5 "2024-05-30T05:55:10Z")

> [@tecosaur](#): > > I will say, when it comes to `dot` / `⋅`, I do think it would be nice if it was defined and exported by `Base`, and `LinearAlgebra` et al. just added methods to it. Agreed - I know we want to keep Base trim, but I think dot products have enough broad utility to be included there instead of LinearAlgebra, with this package being an example of where that’s useful. I also think `similar_type` is important to have because `similar` makes assumptions about the mutability of the type returned, and none of the numeric types this package provides is mutable. > [@tecosaur](#): > > Oh, and the same for `adjoint` / `'`. `adjoint` is defined in Base - I use it in my package. ---

**Author:** ![tecosaur](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tecosaur/32/23206_2.png) [@tecosaur](https://discourse.julialang.org/u/tecosaur)\ **Post date:** [May 30, 2024, 6:09am UTC](https://discourse.julialang.org/t/resolving-name-conflicts-between-my-package-and-other-commonly-used-packages-it-does-not-depend-on/114937/6 "2024-05-30T06:09:53Z")

> [@brainandforce](#): > > `adjoint` is defined in Base - I use it in my package. …I need to adjust some code of mine 😅