Dan Eble <dan@lyric.works> writes: > On 2024-10-04 03:59, David Kastrup wrote: > >> This isn't one. What is more of an issue that a lot of properties >> taking a ly:moment? should rather be taking an exact rational >> (because they will never have grace parts), and the reason that they >> don't is that early versions of Guile did not have exact rationals. > > I am glad you joined the conversation, because I have been thinking > about how to allow setting a musical-length property to a number in > the ly code. > > To avoid disrupting readers, I thought I might try continuing to store > the context property as a moment and support convert-on-set by having > the property's type predicate return the converted value in a new kind > of wrapper smob that marks it as a converted value rather than a plain > old truthy value. The C++ code would detect that and store the > converted value in lieu of the user-provided value. What do you think > of that?
Not much. It makes the default behavior too magic and hand-wavy. > If that seems like a bad idea for some reason, I guess I would skip it > and change musical-length? and positive-musical-length? to accept raw > numbers in addition to moments, change built-in functions like > ly:moment-main to accept numbers and treat them as if they were > moments with only a main part, and update other built-in Scheme and > C++ code as necessary. Some user Scheme code might need to be updated > manually if these things are not enough to keep it working when it > reads a number instead of a moment. I'm not very enthusiastic about > skipping straight to this; I don't like to cause trouble. > > Do you have any other ideas? Provide something like getter/setter functions for properties, provide appropriate compatibility getter/setters for the existing properties and store the actual information in properties with a different name. That allows straightforward behavior and types for the actual properties people are supposed to be using in future while providing read/write backward compatibility under the old names. This also would allow for a phased deprecation (if desired) where after a plentiful grace period use of the old names would lead to nagging. -- David Kastrup
