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/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
