# Am I reaching limits of multiple dispatch?

**URL:** <https://discourse.julialang.org/t/am-i-reaching-limits-of-multiple-dispatch/31479>\
**Category:** General Usage\
**Tags:** question\
**Created:** [November 25, 2019, 8:59am UTC](https://discourse.julialang.org/t/am-i-reaching-limits-of-multiple-dispatch/31479 "2019-11-25T08:59:07Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Janis\_Erdmanis](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/janis_erdmanis/32/10869_2.png) [@Janis\_Erdmanis](https://discourse.julialang.org/u/Janis_Erdmanis)\
**Post date:** [November 25, 2019, 8:59am UTC](https://discourse.julialang.org/t/am-i-reaching-limits-of-multiple-dispatch/31479/1 "2019-11-25T08:59:07Z")

</div>

Recently I implemented some basic cryptographic protocols. One of them is Diffie-Hellman key exchange protocol where only necessity is that the communication channel implements serialize and deserialize methods. Initially, I thought I would only need to import `Serialization` within my module, but soon I found myself in a situation where I needed to import my custom serializer within Diffie-Hellman module. That makes the module `DiffieHellman` more and more specialized where instead, I would like to strive for inclusiveness and compatibility.

How can I solve this issue? More precisely, how can I make the code [DiffieHelmman.jl](https://github.com/PeaceFounder/DiffieHellman.jl/blob/master/src/DiffieHellman.jl) not to depend on `SecureIO` or `Serialization` and make modifications for the tests [runtests.jl](https://github.com/PeaceFounder/DiffieHellman.jl/blob/master/test/runtests.jl) to work?

---

<div class="post-metadata">

**Author:** ![Mason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mason/32/2423_2.png) [@Mason](https://discourse.julialang.org/u/Mason)\
**Post date:** [November 25, 2019, 6:58pm UTC](https://discourse.julialang.org/t/am-i-reaching-limits-of-multiple-dispatch/31479/2 "2019-11-25T18:58:01Z")

</div>

I’m not sure I properly understand what the actual question and problem are or how they relate to the limits of multiple dispatch, but if I understand correctly, you’re asking something along the lines of

> I don’t like that my implementation of a function depend on specific serialization / deserialization functions from another package. I would like users to be able to choose what serialization / deserialization functions to use.

If that’s the case, you could always just add a keyword argument to your functions, i.e.

```julia
diffie(s,sign::Function,verify::Function,G::AbstractGroup,rng::AbstractRNG; 
       serializer::Function = Serialize.serialize, deserializer::Function = Serialize.deserialize)

```

then a user would write something like

```julia
using Some_Different_Serialization_Library: serialize, deserialize
diffie(s, sign, verify, G, rng, serializer=serialize, deserializer=deserialize)

```

If you don’t want your module to depend on Serialize, just don’t provide default keyword arguments, i.e.

```julia
diffie(s,sign::Function,verify::Function,G::AbstractGroup,rng::AbstractRNG; 
       serializer::Function, deserializer::Function)

```

Presumably a similar approach could be taken with your SecureIO dependancy.

You can also look into [Requires.jl](https://github.com/MikeInnes/Requires.jl) for ways to change the behaviour of your code depending on what packages the user has loaded.

---

<div class="post-metadata">

**Author:** ![Janis\_Erdmanis](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/janis_erdmanis/32/10869_2.png) [@Janis\_Erdmanis](https://discourse.julialang.org/u/Janis_Erdmanis)\
**Post date:** [November 25, 2019, 7:54pm UTC](https://discourse.julialang.org/t/am-i-reaching-limits-of-multiple-dispatch/31479/3 "2019-11-25T19:54:53Z")

</div>

I had not thought about putting them as arguments for the function. I kind was focusing on single \<:IO single pairs of serializers. But it actually makes sense to disconnect them. Perhaps indeed that is the way to go 😉