On 2016/08/16 09:09:25, mark_opus11.net wrote:
On 2016/08/12 22:12:43, dak wrote:
> I'm somewhat surprised since I would have thought the _semantics_
reasonably
> straightforward. If the _use_ turns out to be awkward, it could
probably
> amended with a few scheme functions delivering appropriate context
modifications
> or possibly some music function.
>
> I haven't actually bothered doing so so I might be overlooking
something here.
> Can you illustrate some of the occuring problems/awkwardnesses? I
would have
> thought the proposal comparatively straightforward to describe and
use and so
> I'd be interested to know where I was being too optimistic.
Well, whilst it is relatively straightforward to implement, it
also creates the possibility of setting up a situation where the
result is essentially unknowable without fully understanding the
implementation (or trial and error).
For example, what should happen here?
- Staff A
- removal-layer = 2
- removal-friends = #'(b)
- Staff B
- removal-layer = #'b
- Staff C
- removal-layer = 1
Since A's index is greater than C's,
and since A.removal-foes is at its default value of #f
C is set as a foe.
More like "considered a foe": the property stays #f of course. But
effectively yes.
Hara_kiri_group_spanner::request_suicide checks foes before
friends, therefore A will be removed whenever C is present,
regardless of B's existence.
Yes.
Of course this _can_ be documented and explained (that
integer-based layering will trump symbol),
Uh no? Foes trump friends (if we want to avoid the unsavory message, we
can try "poison" and "food" instead which also makes the priorities more
obvious, or something else altogether), but integers and symbols are not
pitted against one another. It's just that integers have natural
friends and foes (when the respective list is #f) and symbols don't.
but I'm just not sure
what we gain from allowing this mediated access to the friends and
foes lists. Whilst adding some considerable complexity to the
codebase.
I don't think it adds considerable complexity to the _codebase_ itself
(at least I think I could do it with comparatively straightforward
changes), and I don't consider the behavement just as irregular as you
paint it. It will complicate the description, and it will create
somewhat complicated use cases for situations that were not possible
before.
At any rate, our evaluations are not all that different and you are the
one who actually tried working with the code so I lean towards trusting
your judgment. I just hope that we don't get hit by use cases which
will again not yield to this code while it might have been approachable
by what _looks_ like a somewhat more general scheme. I really don't
have much more than a gut feeling to work with here.
https://codereview.appspot.com/308910043/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
