On 3/6/2014 11:48 AM, Steve Teale wrote:
I've also noticed from the responses, and from responses to associated
questions, that OOP has become almost a dirty word in the D community.
It's old fashioned and slow. So if you're in that camp, you can stop
reading now.
FWIW, I don't think that's really the prevailing attitude towards OO. OO
definitely has its uses and benefits (and outside performance-critical
sections its performance is perfectly fine), it's just not the
one-size-fits-all mold to force everything into like it often got
treated as ~10 or so years ago.
Even the entity/component-based systems that I mentioned games commonly
use are still frequently employing OO, too (ex: Unity3D uses an
entity/component-based design for game objects, but the API for dealing
with the game object, components, etc is still an OO API). Entities,
metaprogramming, OO - none of these are "either/or" deals, just as OO
doesn't actually try to replace procedural programming but is rather
used together with it.
I need to handle signals of some sort - let's say just represented by an
int.
In my base class I define a method final void handleSignal(int), to
which all signals are directed. In the same place there's a virtual
function bool signalHandler(int).
[...]
Anyone have any bright ideas about how this could be regulated? I can't
say forced, because I think the compiler would have to do that.
A stab in the dark here, but can you just add "bool delegate(int)[]
additionalHandlers" as a required parameter for your base class's
constructor? Then the base class's constructor does "this.handlers ~=
additionalHandlers"
Or maybe something like this?:
class MyBaseClass {
bool addHandlersCalled = false;
bool delegate(int)[] handlers;
/// Subclasses must call this in their ctor.
protected void addHandlers(bool delegate(int)[] handlers)
{
this.handlers = handlers;
addHandlersCalled = true;
}
invariant() {
assert(addHandlersCalled);
}
}
