Re: Allows inner-markup spacing using skylines. (issue 13341044)

[dak]

On 2013/08/29 06:57:53, MikeSol wrote:
> The point is to allow users to achieve the same snug skyline spacing
between
> stencils that is achieved between grobs.

> I agree that it is inefficient as skylines are never cached, but as it
is not
> default beahvior anywhere in the code base, it allows people to decide
on the
> efficiency versus snugness-of-placement trade-off.  For people
creating complex
> markups, this is useful.

Mike, the question is not whether or not it is useful to work with the
distance of skylines.  The problem is that you just pile on complex
derived functionality nilly-willy without stopping to think what the
actually sensible building blocks would be.

And then you defend a lousy design with "it's useful" and "people can
decide themselves on the tradeoff between using a lousy inefficient
design or not".  While it is a popular belief that democracy is a
cure-all, that giving people a choice between different evils somehow
makes them all good, that's not the way to do software development.

Skylines are elusive for markups yet are used in positioning, yes and
that's a problem.  But the solution to that is not to add some more
functions that magically and intransparently do something related to
skylines which might be abused for figuring out some skyline-related
properties.

The solution is to add _proper_ interfaces to skylines.  Functions
that can figure out distances and so on.  Between skylines.

And a function to query the skyline(s) of a stencil, yes.

Now querying skylines is expensive, so the question is how to cache
them.  The important thing to note is that skylines are not actually a
property of stencils but rather of stencil expressions (combined
stencils don't actually contain the original stencils but only their
respective stencil expressions, so caching in the stencils themselves
does not actually help at all).  The current form of stencil
expressions does not make it easy to tack a skyline cache on without
changing object identity, so it might be worth considering a different
representation.

Once that's sorted out satisfactorily and supported by primitives, one
can stack on uses of skylines.

But increasing the number of functions that magically and
intransparently somehow work with skylines not otherwise accessible is
just a bad idea, and hiding this kind of thing in existing functions
is even worse.


https://codereview.appspot.com/13341044/