Re: Uses only unpure-pure containers to articulate unpure-pure relationships. (issue 7377046)

[dak]

On 2013/02/23 05:35:50, MikeSol wrote:
> Some code from my patch for issue 3161 is copied over to this patch.
The fact
> that Grob::pure_height returns Interval (0,0) as default causes point
stencils
> to be placed in the skyline, potentially effecting vertical spacing.

> Separation_item::boxes uses this (0,0) extent to add extra spacing
height to
> certain grobs.  To allow this to still happen, we give the grobs
without pure
> height a small empty extent so that the (almost) full compliment of
extra
> spacing height is taken into account.  This is why
small-empty-interval exists
> in lily-library.scm.

Mike, you need to work on your problem solving strategies.  The
problem to solve is:

Problem: for some stencils, the pure values are not distinctive enough
to differentiate even between empty and non-empty results.  Adding
extra spacing height to empty intervals, however, has no effect.

Solution: mess with the internals of intervals to create a different
flavor of empty intervals (that the interval code is not actually
designed for supporting and that is total nonsense with regard to the
mathematical model underlying the Interval type), some of which will,
when given extra height above an arbitrary threshold, will mutate into
non-empty intervals that almost, but not quite, correspond to giving
extra height to a point stencil.

Seriously?

You stated previously that your programming workflow does not allow
writing comments in advance since you are not actually planning
anything, but the plan emerges while you code.

But then you should at least write the comments afterwards and check
whether the plan which emerged is not totally insane.

There are several obvious solutions for tackling this:

a) when extra-height is considered and not set to (), treat empty
heights as a point-stencil at (0,0) instead.

b) make sure that the pure stencils at least share the emptiness or
non-emptiness of unpure stencils by appropriately defining them.

Now if you bothered actually documenting your approaches instead of
just hoping nobody will notice (I discovered the
"small-empty-interval" junk more by accident than anything else and
assumed it was intended to save you from fixing you some bug rather
than suspecting that it was supposed to be an exploit of the current
Interval implementation saving you from fixing your design), the
probability that you leave such time bombs in the code would be lower.

And make no mistake: this is a time bomb.  It would be totally
reasonable to change the implementation of Interval to make sure that
offsetting an empty interval can never make it (by virtue of numerics)
become a point interval.  And it is quite probable that at some point
of time the internals will be changed along that line, just making the
offsetting of empty intervals a noop in the implementation,
corresponding to what the underlying concept behaves like.


https://codereview.appspot.com/7377046/