Luca Fascione <[email protected]> writes: > On Thu, Aug 27, 2026 at 10:08 AM David Kastrup <[email protected]> wrote: > >> Luca Fascione <[email protected]> writes: >> >> In this case, it isn't actually a "base" but essentially the full >> thing. The only way in which a book and bookpart differ is in their >> relationship and use: a book can have bookparts. >> > > 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. That makes it hard to decide what to do with \some-book since there is very little to figure out whether some-book originated from a \book or a \bookpart construct. > so why not call it part collection? (Or something that means > that). It's that case with the recursive data structure I was talking > about before, no? Like, I think I hear you say that a book is a > SetOfParts (well, ordered, obviously, so maybe not "set"). Because it is just clumsy. At some point of time, logic needs to take a backseat to readable and handable code. > Indubitably, I'm just soundboarding here in the hopes that verbalizing > through it helps see the way forward better. I am leaning towards \book Book ly:book? "book" \bookpart Bookpart ly:bookpart? "bookpart" * Book_item ly:book-or-bookpart? "book or bookpart" It would be a convert-ly job to convert all uses of ly:book? to ly:bookpart-or-book . I lean towards treating "bookpart" as a single word even in the plain language description rather than the compound "book part" because a \bookpart is a specific entity and type in LilyPond. -- David Kastrup
