Luca Fascione <[email protected]> writes: > On Thu, Aug 27, 2026 at 11:11 AM David Kastrup <[email protected]> wrote: > >> Luca Fascione <[email protected]> writes: >> >> > On Thu, Aug 27, 2026 at 10:08 AM David Kastrup <[email protected]> wrote: >> > >> > I'm just being overly analytic here, David, but I think I'm hearing >> > you say that this thing currently called "book" is really a >> > "collection of parts", >> >> No, it isn't. Or rather, we have a Book class that implements both what >> LilyPond invokes as \book and what LilyPond invokes as \bookpart, that >> class contains everything that either a \book or \bookpart needs, and >> there are functions cobbling them together without bothering to >> distinguish them. >> > > Yes I realize that, indeed this is where it all started, I was meaning > "book" sans its "bookpart"... part. > You know, just in its incarnations where you're not considering its > "bookpart" potential. > > I thought you were heading in a direction where "one Book class to do two > things is a bad idea", > and wanted to cut that class up into pieces, you see. I may have > misunderstood what you meant before then.
The problems essentially are: books and bookparts are hard to distinguish at all right now even though there are two different keywords to create either of them, and there are things you should not be doing with one or the other, and those things are supported with data fields of their own. So just storing an "I am a bookpart" flag seems rather not-C++-ish. There are two ways out: eradicate the differences, or enshrine them. After some discussions on the list, I think it may be saner to enshrine them. -- David Kastrup
