Something that I have been doing quite heavily recently is a
registration approach. I.e. in a module constructor (shared) you
call a function giving it a class type that most likely inherits
another class/interface. From there code is generated/executed at
compile time for that function call. Very useful for registering
e.g. routes.
However an issue with this approach I've seen while porting glfw
to D is that sure this works but how can I do e.g. new
Window(640, 480, "My title here"); when it needs to hook into the
registration system to grab the real window implementation that
you have set to use by default (or overridable by adding the name
to the call).
This is essentially the factory pattern.
Now something that allows me to say the function allocates this
class but not its children would really be useful. As I could get
it to go to the registration system and grab the allocated result
from there.
Based upon this what you're thinking of is essentially
add/override methods on a class which is really isn't good D
code. Too much like c++ and ugly.
Perhaps what we could have to accomplish your part while making
it obvious is a sorta like how c#'s event support is.
Now we could implement this as a mixin template. I.e. it could
generate:
static void method_addHandler(T)(del)
in {
... // check if del is a delegate with matching definition
// first arg must be previous value
} body {
... // add arg to list
}
T method(ARGS) {
... // run handlers while passing previous value
}
With this you could also pass e.g. a lambda or some delegate to
the mixin to say this is my default output of this method. Can
also do some checks for default return types ext.
I don't know how to handle access modifiers for this. However
pretty much everything else is doable without changing the front
end specially for this use case. Will depend though on the
allocation api and if it'll allow you to return a child class
type. I don't see why it wouldn't though.
But this is just my thoughts on the matter. I'm sure somebody
will destroy it!
