Luca Fascione <[email protected]> writes: > I think this is a key reason why "Item" should not be used here. It's > a distant part of the code and you would give it an unrelated meaning. > It lowers cognitive overhead on the part of the reader to not have to > go and think that an "item" in <these files> means a grob-ish thing, > while if you are in <those files> it means a book-ish thing. I know > this wouldn't be the entire name of the Type, but it still helps. And > again, "base" has served me and my colleagues well is in this role of > root of a collection of somewhat related things. It's less attention > devoted to this aspect, that can be repurposed for other, likely more > valuable work.
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. That is quite different to how Smob_base relates to a Smob or Simple_smob or Smob1: all of those are really different and the Smob_base only serves as a common conduit so that they may be interfaced in the same manner. Because of that "basically a book" thing, calling it a book (like it is done now) may also be an option, but it is awkward to say "a bookpart is a book that is part of a full book (?)" and the term "bookpart" is already established at the LilyPond language level. For better or worse, LilyPond already hogs quite a few common English compound name components. I don't think it makes sense to become overly cute like calling that base class a "Fascicle". It makes more sense to pick something that says "basically a book" in a manner that would also work with other entities, and in spite of the common word root, "book base" suggests something quite less complete. Given the amount of C++ code Dan churns through, I might also be inclined to listen to his LilyPond word sense: he might be running across any finalized choice a whole lot. -- David Kastrup
