Sorry, what you mean by that is not very clear to me.
What I mean by interfaces is something like this (note all the code above is merely an example, not real code):
module Plottable # this is the interface
function plot end
end
function Plottable.plot(x :: Point, canvas :: Canvas)
end
function Plottable.plot(x :: Frame, canvas :: Canvas)
end
function plot_in_pdf(x, filename)
# create a canvas object
Plottable.plot(x, canvas)
# output the plot to the filename
end
Basically, define a set of functions inside a module (Plottable in this case). And then you extend that functions for your concrete types (Point, Frame, and so on, I left the type parameters out for simplicity). Finally, you define a generic function which does not specify the types of the parameters implementing Plottable and just call the interface functions (the only one is Plottable.plot in this example) over such generic parameters. This is extensible: you can have as many different interfaces you want, and each concrete type may implement as many interfaces you want them to implement. One drawback is that this strategy alone does not deal with multiple fallback methods. This is, for each function of the interface: you will have one method for each concrete type, and maybe you will have one fallback method for Any (which may error and point out that you should implement the interface, or try to execute calling other more primitive functions of the same interface). If you start to define fallbacks (or even generic functions that should work over the interface) but restrict the type of the parameters to GeometricEntity2D, or any other abstract types, then you will start having the same problem again, because at some point you will want the same concrete type to inherit two different abstract types so it has access to all the functions you want it to have access. The solution I delineated here, therefore, is not restricting access: accept any type and expect it to implement the necessary interface.