How to define multiple dispatch, when we have so many structs? - julia

Question

If we have a few structs, using multiple dispatch isn't a problem.
But when we have so many struct, how to use multiple dispatch?
For example, we have N structs like this:
struct An
a::Float64
end
And a function like:
f!(a::Ai) = exp(Ai.a)
When N is large, it will be a headache.
Consider that this function is simple and easy! A function could be so large!

Answer 1

If the function definition is the same for all the structs, you could define them as a concrete type of some abstract type, and leave only one function that dispatches on the abstract type:
julia> abstract type Allmystructs end
julia> struct A1 <: Allmystructs
a::Float64
end
julia> struct A2 <: Allmystructs
a::Float64
end
julia> f(A :: Allmystructs) = exp(A.a)
f (generic function with 1 method)
julia> test1 = A1(5)
A1(5.0)
julia> test2 = A2(8)
A2(8.0)
julia> f(test1)
148.4131591025766
julia> f(test2)
2980.9579870417283
Of course, this may not be what you are looking for if the function definition for each type of struct is different. In that case, metaprogramming can be your friend.
Edit: Typos.

Answer 2

You can enumerate the names of your structs in a loop, and use #eval to generate and evaluate code for each of them:
julia> for S in [:A1, :A2, :A3]
#eval begin
struct $S
a::Float64
end
f(x::$S) = exp(x.a)
end
end
julia> A2(2)
A2(2.0)
julia> f(A2(2))
7.38905609893065
I here defined the structs in the same place, because I was trying it out in the console.
But there might be a better alternatives to this. eval is usually considered a sign of suboptimal design.

Answer 3

Usually when code has a lot of very similar structs, this suggests that maybe composition is an alternative.
As an example, suppose we have a colored geometric shape library with a lot of different structs:
const Point = Tuple{Float64, Float64}
struct Disc
center::Point
radius::Float64
red::Float64
green::Float64
blue::Float64
end
struct Rectangle
topleft::Point
bottomright::Point
red::Float64
green::Float64
blue::Float64
end
# ... etc., e.g. Triangle, Hexagon
Now suppose we want to introduce a luminance() function which returns the perceived luminance of the color of the shape. One way is to define a method for each struct, but since the methods are all the same, we can also do:
const Shape = Union{Disc, Rectangle, Triangle, Hexagon}
luminance(shape::Shape) = 0.299*shape.red + 0.587*shape.green + 0.114*shape.blue)
This is still a little annoying because we need to have all the shapes available in one place in order to list them. Adding new shapes would be a hassle. So indeed, we can make an abstract type Shape end and have each shape subtype it, as suggested in the accepted answer. But in many ways, this approach is still unsatisfactory, because it constrains all future Shapes to share the same layout!
A better way to approach this problem is to decouple the red, green, and blue properties shared by all the colored shapes. Thus we introduce a type hierarchy as:
const Point = Tuple{Float64, Float64}
struct Color
red::Float64
green::Float64
blue::Float64
end
abstract type Figure end
struct Disc <: Figure
center::Point
radius::Float64
end
struct Rectangle <: Figure
topleft::Point
bottomright::Point
end
struct ColoredShape{F <: Figure}
figure::F
color::Color
end
Now, instead of using Rectangle((0.0, 0.0), (1.0, 1.0), 0.5, 0.5, 0.5) to represent a gray rectangle, we would use ColoredShape(Rectange((0.0, 0.0), (1.0, 1.0)), Color(0.5, 0.5, 0.5)). Instead of defining multiple identical luminance methods, we would define it just once for the Color struct. (You could also, optionally, define another method for ColoredShape that delegates to the property color, but this is only one additional method instead of N!) This pattern also allows the functionality we define for colors to be reused across other contexts, besides colored shapes.
In general, it is preferable to split concepts down to the smallest digestible pieces for re-usability and understandability. If there are lots of very similar structs, such that defining functions for all of them seems to be a chore, this would suggest that there could possibly be some shared functionality to factor out.