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/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel