Cumulative

Steve Teale steve.teale at britseyeview.com
Thu Mar 6 08:48:44 PST 2014


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


More information about the Digitalmars-d mailing list