Algorithms should be free from rich types
Ali Çehreli
acehreli at yahoo.com
Tue Jun 27 21:53:59 UTC 2023
My mind is not fully clear on this topic yet but some related things
have been brewing in me for years.
First, an aside: You may remember my minor complaint about 'private'
during a DConf presentation years ago. Today, I feel even stronger that
disallowing access to parts of software "just because" of good design is
a mistake. I've seen multiple examples of this in professional life
where a developer uses 'private' only because it is "of course" better
to do so. (The Turkish word "işgüzar" and the German word
"verschlimmbessern" describe the situation pretty well for me but the
English language lacks such a word.)
To give an example from D's ecosystem, the D runtime's garbage collector
statistics object used to be 'private'. (I think there is an interface
for it now.) What an inconvenience it was to copy/paste that type's
definition from the runtime to user code, get the compiled symbol of the
object from the library, and pointer cast it to be able to access the
members! A 'static assert' attempts to protect the project from changes
to that type...
The idea of 'private' should be to just give the developer freedom to
change the implementation in the future. It should not impede use cases
that people come up with. That can be achieved practically with an
underscore: Make everything 'public' and name your implementation
details with an underscore. People who need them will surely know they
are implementation details that can change in the future but they will
be happy: They will get things done.
Ok, that rant is over.
The main topic here is about the harm caused by rich types surrounding
algorithms. Let's say I am interested in using an open source algorithm
that works with a memory area. (Not related to D.) We all know that a
memory area can be described by a fat pointer like D's slices. So, that
is what the algorithm should take.
Unfortunately, the poor little algorithm is not free to be used: It is
written to work with a custom type of that library; let's call it
MySlice, which is produced by MyMemoryMappedFile, which is produced by
MyFile, which is initialized only by types like MyFilePath. (I may have
gotten the relationships wrong there.)
But my data is already in a memory area that I own! How can I call that
algorithm? Should I write it to a file first and then use those rich
types to access the algorithm? That should not be necessary...
Of course I understand the benefits of all those types but the core
algorithm should be as free as possible. So, this is simply wrong. I
think us, software developers, have been on the wrong path. Our task
should primarily be about getting things done first.
I could work with those types if they had virtual interfaces. But no.
They are un-subtypable C++ 'class'es.
I think it could also work if the algorithm was templatized; but again,
no...
Hey! Thank you! I feel better already. :)
Ali
More information about the Digitalmars-d
mailing list