On Thu, Aug 27, 2026 at 4:49 PM David Kastrup <[email protected]> wrote:
> 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 I have a question: you have a bookpart object, and this I'm guessing is conceptually a sequence of... scores or so, right? My question is: what's the business of a book object being able to _actually_ be a bookpart, why can't the book just be a sequence of bookparts instead? Like, in the source lilypond file you can just make a Staff in the middle of nothing, and the program will make for you a Score to wrap it, right? What is the defense for not doing the same thing with books and bookparts? (ie. bookpart only ever is an "honest" bookpart, and if there is a need to treat it like a book, a Book is made on your behalf and placed "around it", like the Score and Staff relation). Wouldn't it simplify everything to remove from Book class definition all the stuff that is in BookPart and then make the Book class definition _have_ a BookPart member (indeed a collection thereof, to be precies) to restore the functionality? In other words I'm wondering if this difficulty in finding a convincing solution shouldn't be taken as an indication that the present OO modeling is a poor match for the ontologies at play. just storing an "I am a bookpart" flag seems > rather not-C++-ish. > Indubitably. But it's really not even an OO good practice anyways, it's not just a C++-specific problem. > 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. > FWIW, I guess my inclination from hearing this story would also lie in this second camp, yes. L -- Luca Fascione
