Re: Member-function callbacks (was Tie: add some C++ rigor and concision)

[David Kastrup]

> I am not top posting

I am not able to find the article that I am replying to here in the
mailng list.

Dan Eble <address@hidden> writes:

> On Jul 23, 2015, at 00:55 , David Kastrup <address@hidden> wrote:
>> Dan Eble <address@hidden> writes:
>>> One thing that is obviously incomplete is that the final classes are
>>> not derived from Grob.
>
> For example, after I run the script you provided, there is this:
>
>     class Accidental_interface
>     {
>     public:
>       DECLARE_MEMBER_CALLBACK (print, ());
>       DECLARE_MEMBER_CALLBACK (horizontal_skylines, ());
>     // etc.
>
> This can not work as written because the implicit argument is a kind of Grob, 
> which can not be cast to an Accidental_interface.
>
>> match (I think the next step I was planning on is figuring out per
>> script which stuff was derived from the right classes for doing this
>> kind of change).

Well, the history of this change was that I gave up on working on the
script pretty much exactly because it was doing too much and I would
have required quite a bit of information collection (or hand-editing) to
figure out where the changes were compatible with the type hierarchy and
where not.

> I see these options:
>
> 1. Take an entirely different approach to organizing the interfaces,
> after careful thought as suggested in
> https://code.google.com/p/lilypond/issues/detail?id=4564#c7

Well, that would take care of the proper type hierarchy.  Of course, the
interface class itself still would be empty.  The logical long-term goal
would likely be to populate it with the properties belonging to the
interface and replace all get_property ("something") calls in the
interface member functions with something_ .  Which would likely require
a careful overhaul of class Grob_properties to keep it working well.

> 2. Derive interface classes from Grob (in some cases a subclass of
> Grob might be appropriate) and abuse the pointers, which is where I
> thought you were going with this at first.

Uh, that's where my automatic conversion went.  Which is why I stalled
this project.  I don't like static_casting around this problem (which is
what your derivation rule is about, basically relying on interface not
having any members of its own) and I'd not like reinterpret_casting
around it either (which would not require any derivation).

However, any static_cast would go Grob->Interface and would likely
happen in trampolines, so there is not much in terms of ugly code going
around, and moving to virtual inheritance and populating the interfaces
with data members of their own would not require changing the bulk of
the code which would continue to rely on Grob being a base class of the
Interface.

> 3. Restrict member callbacks to the handful of subclasses of Grob that
> exist now.

Well, subclasses of Grob are likely still going to be a headache
regarding 2.

-- 
David Kastrup