#4885 Remove ack_finder/ack_find_base

[David Kastrup]

Remove ack_finder/ack_find_base

ADD_ACKNOWLEDGER and ADD_END_ACKNOWLEDGER can work without them when
the base is specified correctly when calling them inside of some
CLASS::boot ().

Also contains commits:

Let ADD_ACKNOWLEDGER state actual classes

Declaring the correct containing classes for acknowledgers
allows dropping a bunch of black magic.

Simplify ADD_{,END_}ACKNOWLEDGER

No explicit scopes are needed any more since they are run from within
the static member function CLASS::boot () .

http://codereview.appspot.com/295480044

[David Kastrup]

Pushed to staging as
commit b9040afd1dcfbee6b45bc3d54850ff50d51c8ee9
Author: David Kastrup dak@gnu.org
Date: Sun Jun 5 20:48:36 2016 +0200

Issue 4885/3: Remove ack_finder/ack_find_base

ADD_ACKNOWLEDGER and ADD_END_ACKNOWLEDGER can work without them when
the base is specified correctly when calling them inside of some
CLASS::boot ().

commit 7c36dbb1834c7c68e4b94777241de3ea02971aca
Author: David Kastrup dak@gnu.org
Date: Sun Jun 5 21:10:00 2016 +0200

Issue 4885/2: Let ADD_ACKNOWLEDGER state actual classes

Declaring the correct containing classes for acknowledgers
allows dropping a bunch of black magic.

commit ee2b56da1f1c2d7affd4e48a7f3c11b53ff85df0
Author: David Kastrup dak@gnu.org
Date: Sun Jun 5 16:17:44 2016 +0200

Issue 4885/1: Simplify ADD_{,END_}ACKNOWLEDGER

No explicit scopes are needed any more since they are run from within
the static member function CLASS::boot () .

[David Kastrup]

Ok, this is a real nuisance. It would appear that the C++11 rules for access to protected members does not permit a derived class to name them as &Base::member but requires naming them as &Derived::member even though the resulting type will be Base::*. While this patch did make a number of members public as part of the middle commit (more or less muddling through and wanting to clean this up later), I was not all that aware of this rather fundamental consequence, instead suspecting some other fluke I could fix up later.

In addition, the same kind of ack_finder magic removed by this patch is rather unavoidable for translator_listeners. So this patch does not help in reducing the scope of necessary complexity while requiring inherited acknowledgers to be accessible by anybody rather than just the Engraver implementation and derived classes.

Consequently, I will be reverting it except for the first patch in the series while the reverts are still reasonably easy to do.

[David Kastrup]

Consequently, I will be reverting it except for the first patch in the series while the reverts are still reasonably easy to do.

Which they aren't because of issue 4887. Pffft. Ok, some more work involved here...