Dan Eble <dan@lyric.works> writes: > On 2024-10-04 17:58, David Kastrup wrote: >> Dan Eble <dan@lyric.works> writes: >> >>> Taking all the feedback into account, I plan to prepare a patch >>> renaming baseMoment to beatBase. >> How about doing both rename and retyping to rational and keeping the >> old >> property as a Moment-typed compatibility read/write accessor? >> That would be less of a compatibility nightmare. >> > > I recently discovered that baseMoment is also used as an alist key in > the value of the timeSignatureSettings property. Allowing a > deprecated baseMoment context property to parallel a new beatBase > context property would not address that alist, so I've been thinking > about what to do instead. > > I'm looking for opinions on going ahead with the parallel property > idea, but implementing a very broad replacement of baseMoment with > beatBase in convert-ly. That would break user Scheme code that was > previously using baseMoment as a moment, but give authors a choice > between two fixes: > > * Short term: reverse the replacement to continue working with moments > * Long term: revise the code to work with plain numbers
I took a look at the code, and the baseMoment property in the timeSignatureSettings alist has type rational and is autoconverted to a Moment when it is being used for setting the property. This is garbage, but it is in a separate garbage can. The baseMoment property in the alist just shares a name with the baseMoment context property and the values are not interchangeable. If you want to provide a deprecation period here, you can search for both the both the old and new name (probably falling back to the old name only when the new one isn't found) and complain about old name use. The value, incidentally, will be of the same type. -- David Kastrup
