Resolving name conflicts between my package and other, commonly used packages it does not depend on

General Usage
,
1

My package, 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 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.

2

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.

3

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.

4

Oh, and the same for adjoint / '.

5

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.

adjoint is defined in Base - I use it in my package.

6

…I need to adjust some code of mine :sweat_smile: