On Sunday, 16 July 2017 at 17:24:17 UTC, Jean-Louis Leroy wrote:
TL;DR: see here
https://github.com/jll63/methods.d/blob/master/README.md for an
explanation of what open multi-methods are, if you are not
familiar with the idea.You may also want to read my article on
Earlier this year I attended Ali Çehreli's talk at C++ Now. He
did a good job: I walked out with the desire to learn about D
and see how it measures up against C++, especially in terms of
meta-programming and language extensibility. The first
programming language I learned is Forth and I did some Lisp
programming, so as you can imagine, my expectations are high.
As an experiment, I decided to try to port parts of my yomm11
library to D. The experience turned out to be pleasant and I
ended up writing a full implementation, with some friendly help
from Ali and others in the Learn forum.
I think that what I have now is good enough to show. The git
repo is here https://github.com/jll63/methods.d and I will post
a package to the registry soon.
If you have the inclination, feel free to review and comment.
This is my very first D project and I certainly have missed
some idioms and been clumsy at times.
Interesting. One problem I think the above approach has is adding
methods after compilation. Say, a plugin adds a new derived
matrix type SparseMatrix and wants to customize the addition of
them. This is impossible under the current model, is it not?
Would it not be possible create a sort of "externmultimethod"
that mimics extern'ing a method? Basically, on the "server/host"
side there is a method that can be used to add new multimethods
at runtime. It takes meta data and extends the virtual table to
handle dispatching it along with the other functions. The
"client/plugin" side has the multimethod it wants to add to the
dispatch and it does this by giving it all the needed information
to do so and using the new externmultimethod method to do it.