Re: [GSoC] Implement cross-voice dynamic spanners (issue 304160043 by address@hidden)

[dak]

https://codereview.appspot.com/304160043/diff/80001/lily/include/spanner-engraver.hh
File lily/include/spanner-engraver.hh (right):

https://codereview.appspot.com/304160043/diff/80001/lily/include/spanner-engraver.hh#newcode111
lily/include/spanner-engraver.hh:111: if (is_manager_)
On 2016/10/21 13:22:53, dak wrote:
> Ok, this is_manager_ concept seems like a bad fit with regard to the
overall
> data structures.  It means that every engraver instance here has all
the
> functions and data structures needed to manage multiple engravers.

> What are alternative means of doing this?

> The simplest would likely be to have the multiple spanner class be
templated on
> the class it is controlling.  It would then create actual engravers as
needed.
> To get equivalent behavior, it might seem that one engraver instance
should be
> created right away.  However, since the multiple-spanner-ready
engravers need to
> be prepared to be created later than that anyway, I think I'd just
create them
> as needed even for the default one.

> The advantage would be that the hierarchy would be much cleaner:
currently I
> feel that there is code distributed up and down, making it harder to
track
> responsibilities and consequently also for figuring out how to work
this into
> slurs and others.

> Now the question is how such a rearrangement would best be organized:
we don't
> want the code fall dead, but the time allotment for the project also
is
> basically over.  See a perspective here time and motivation getting
this
> simplified?

Sorry that's a bit confused as Spanner_engraver is already templated on
its controlled class.  The point is that the controlled class is derived
from Spanner_engraver<Class> which has the advantage that this can
provide the same machinery as Engraver but do it differently.  But it
has the disadvantage that the actually running "master" Engraver is
running multiple instances.  So maybe one needs to shoehorn the
one-spanner engraver in question between a single master Engraver
instance (so necessarily being a separate type from the individual
engravers not sharing inheritance) receiving and redistributing the
events and have some interface class in closer relation to the
individual engravers (either being derived from the individual engraver
class and exercising its interfaces while using virtual functions to
take over the underlying Engraver functions, or by being its base class
instead of Engraver and reimplementing the base functionality).

https://codereview.appspot.com/304160043/