lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sets TabVoice Stem height to ##f (issue 6303065)


From: dak
Subject: Re: Sets TabVoice Stem height to ##f (issue 6303065)
Date: Tue, 12 Jun 2012 14:09:35 +0000

On 2012/06/12 13:47:34, MikeSol wrote:
On 2012/06/12 13:43:09, dak wrote:

> If a type is named "Interval", it needs to be employed as an
Interval, not as
> something totally different that relies on implementation details.
>
> Otherwise type abstraction makes code _less_ maintainable rather
than more,
> since you always need to take all side-effects into consideration.

Dunno - it sounds like time for clean up.

Maybe.  It does not make sense in my opinion to pepper the whole code
with fixups intended to cater for cases where intervals are supposed to
be used as non-intervals, or with fixups in order to cater for cases
where intervals are supposed to be used as intervals, and we can't put
the respective fixes into the interval implementation itself since it
would violate the assumptions of those uses where intervals are used as
non-intervals.

Y-position of beams were stored as intervals for years (they may still
be - I
forget).

Storing Y-positions of beams in intervals is fine when we are talking
about a possible set of definitions for Y-positions at one point.  When
we are talking about "lower interval bound is left Y-position, higher
interval bound is right Y-position, and left Y-position may be higher
than right Y-position", we are venturing into the domain of nonsense.

This sounds like a pretty major task, so as always, I'd touch base w/
Han-Wen to
see what Intervals were supposed to be at their inception and then
evaluate what
they've grown into.

We can then firm up an Interval API and write a strongly-worded
comment in
interval.hh and interval.tcc NOT to touch either of these files.

Sounds like it would make sense.  And _if_ we have use cases for ordered
point/value pairs (like using Linear_combination or whatever), then we
should make sure that those are available on _appropriate_ data types as
well rather than misusing Intervals for them because their internals
happen to be convenient for that.

http://codereview.appspot.com/6303065/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]