Re: Introduce a Grob_interface class (issue 251700043 by address@hidden)

[David Kastrup]

Dan Eble <address@hidden> writes:

>> On Apr 30, 2016, at 05:37 , address@hidden 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