Dan Eble <d...@faithful.be> writes: >> On Apr 30, 2016, at 05:37 , d...@gnu.org wrote: >> >> Ok, I need a refresher here. What was the ultimate aim of this >> patch/issue? As it stands, actual interface classes like >> Axis_group_interface don't have _any_ connection to a type any more. >> Instead, there is a Grob_interface template class depending on them with >> an arbitrarily named single instance not used for anything but >> initialization. > > I’m sorry I can’t give much of a refresher. I’ve been busy on > unrelated projects for months. > > This comment: > >> T::has_interface (grob) has become has_interface<T> (grob). (Like >> unsmob<T>, it has the advantage of not being inherited by derived >> classes of T.) > > ... reminds me--if I recall correctly, which might not be the > case--that a trigger for this patch was the belief that if one called > Derived::has_interface(grob) and had neglected to implement > has_interface() for the derived class, the question would be answered > by the nearest base implementation, and that would be the wrong answer > to the question.
No, I think that was for unsmob when used as a type checker. Or something like that. I don't think that we have any inheritance with regard to interfaces, and it would have been quite pointless anyway since they only had static member functions so that there was nothing worthwhile to inherit (apart from possibly protected static member functions but I don't think there ever were any). I think this was more in the course of having "this" be the respective Grob* of the grob accessed by the interface. But getting there would really mess with the type system I think. > If it hampers your greater clean-up, throw it away. At the current point of time, I am changing the acknowledger macros from something awkward to something awkward. I was just brainstorming about how this could ultimately be streamlined into something C++-like as well, but I think it would be a bad idea to try refactoring this as well right now. It's more the temptation of doing something here that is hampering the current work by having me brood over non-imminent stuff. But the smart idea is to just stick with it here. My problem is that some acknowledgers are inherited right now, and this inheritance works with a rather ugly combination of DECLARE_ACKNOWLEDGER inside of a base class with ADD_ACKNOWLEDGER outside of a derived class, and each of those macros only talks about its own class. So the required initialization function defined in ADD_ACKNOWLEDGER cannot be a static member function since DECLARE_ACKNOWLEDGER (the only thing called _inside_ of a class definition) would declare it in the base class. I'll likely just do something boringly stupid, like redefine the acknowledgers in the derived class to call the base class acknowledgers and thus get rid of the whole "&T::grob_acknowledger is not of type void (T::*)(Grob *) but of type void (B::*)(Grob *)" issue for this iteration. If I could have done the initialization with a static member function, I could have used a class-local template override to do the right thing (because then I would have been in the namespace of the derived class), but the initialization happens at global namespace. After the local acknowledger redefinitions, that template override scheme would work but stop being necessary. Well... Redefining the local acknowledgers as deflectors to the base class acknowledgers seems rather like defeating the whole idea of inheritance in the first place. But the half-baked macro system does not really lend itself well in the current incarnation to anything else, and replacing its incarnation with something else altogether seems exaggerated. So I am deadlocking between several different ugly approaches. I'll probably pick one of the uglier ones as long as it's simple. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel