Mike Solomon <m...@mikesolomon.org> writes:
> On 13 août 2013, at 12:41, David Kastrup <d...@gnu.org> wrote:
>
>> We don't need a
>> whole reimplementation of old code for the sole purpose of temporarily
>> masking bugs with the new implementation by retro-fitting a distant
>> clone of the old implementation on top of the unfixed new
>> implementation.
>
> I put up a patch that reimplements the pure-relevant distinction. The
> goal would be to set all problematic grobs to #f. This allows the
> current mechanism of articulating all unpure-pure relationships via
> containers rather than lists while at the same time avoiding the bug
> in 3385. What would be more elegant is for all grobs to be pure
> relevant and for the height functions to not trigger unwanted side
> effects. I feel this is a better alternative than reverting the
> patch.
Sorry, but that's rubbish. You know as well as everyone else that you
won't have either time or inclination to fix the original patch
properly: the whole point of this add-on patch is to avoid having to do
a proper fix by getting a band-aid add-on.
And the purpose is to reach a state fit for a stable release, so
obviously this code is supposed to be in a state fit for reference and
will stay around for a long time.
If anybody is going to actually look at it, we get to something like:
oh, you use pure/unpure containers to formulate the relation. Why
then does the code use pure-relevant here?
Oh, you are not supposed to do it that way, we put that just in
because we were too lazy to figure out how to make the correct way
work.
So you propose leaving the code in a state where there is no longer a
correct way to do anything, and where two different ways of doing things
will interact in unknown ways.
If the original design is so fragile that it is not feasible to get it
right with a reasonable amount of effort, then the only consequence is
to _scrap_ it, completely. Revert. And pick a different design next
time.
It does not make sense to keep code in that nobody can figure out how to
make work right except by overriding its operation.
The solution to unmaintainable code (and if it is not possible to make
the code work correctly in a reasonable time frame, it _is_
unmaintainable) is not more code on top of it.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
