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
--
Dan
