Cumulative

[Shammah Chancellor]

On 2014-03-06 16:48:44 +0000, Steve Teale said:

> On Monday, 24 February 2014 at 08:41:06 UTC, Steve Teale wrote:
>> 25 years ago, when I was trying to write some sort of library to go 
>> with Walter's C++ compiler, I had a wish, and it still pops into my 
>> head from time to time.
>> 
>> What I wanted was functions that were declared in a base class as 
>> 'cumulative', or something similar. They would have been generally like 
>> virtual functions, except that any derived class that wanted to do 
>> something extra - as opposed to something different, would simply 
>> define an 'extend', and just specify the extra code. The compiler would 
>> then automatically add a call to the same function in whatever base 
>> class last defined or extended the method.
> 
>> OK, I'm back to this because I have done quite a bit of work trying to 
>> get to what I wanted. I have converted my app so that it conforms 
>> roughly to the above, as a test.
> 
> 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.
> 
> 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).
> 
> The base class also has a data member bool delegate(int)[] handlers.
> 
> In classes Base, Intermediate, and Leaf, say, the constructor has a statement:
> 
> handlers ~= &Base.signalHandler;
> handlers ~= &Intermediate.signalHandler;
> handlers ~= &Leaf.signalHandler;
> 
> The final handleSignal() method in the base class just traverses the 
> array, calling each delegate in turn until one returns true, and then 
> throws an exception or something if none of them do.
> 
> This works nicely. A lot of duplicate code in my original handler 
> functions is eliminated. Any particular leaf class just has to cover 
> the cases peculiar to it's own requirements. Intermediate classes just 
> deal with their generic cases, and the base class handles all the 
> signals that all leaves require.
> 
> The compiler doesn't help to ensure that the 'handlers ~=' bit is 
> present in all constructors, so I thought I would be clever, and 
> provide some mixin template or template function that all the 
> constructors in the hierarchy used, so that it was a fairly simple 
> thing to insist on, even if only by example.
> 
> But I have been frustrated in this desire. A member function like
> 
> final void doMyThing(string CLASSNAME)()
> {
>     handlers ~= mixin("&"~CLASSNAME~".signalHandler;");
> }
> 
> defined in the base class does not work, because the compiler complains 
> about the type of the this pointer being Base, despite the fact that I 
> am being explicit about the class name.
> 
> Attempts from other directions like calling back down the super() chain 
> don't work because I can't have anything but declarations in a mixin 
> template, and a super() call inside a template function called by the 
> constructor fails because the call is not in a constructor.
> 
> 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.
> 
> Steve

I understand what you want to do, I'm just not sure I understand the 
use-case.  However, you may be interested in this code for some ideas 
for possible alternatives: 
https://github.com/schancel/gameserver/blob/master/source/connections/igsconnection.d#L148 


-S.