> > Instead of the old interface use this deprecated new interface, > instead of just: Use the same interface, but you will need to add a type > conversion.
The deprecated properties aren't intended for end users to write in their code. New human written code should use the non-deprecated names and just use exact rationals instead of calls to make-moment. The deprecated properties provide a way for convert-ly to modify code so it still compiles without requiring automatic conversions applied to potentially arbitrary Scheme code. It also means that once code is converted with convert-ly, compiling it will print deprecation errors so that users are aware they need to convert the values to exact rationals going forward. The goal being not that users wrap their code in type conversions, but actually update the type used. ...while a proper warning to a deprecated function should be something like: > "X is deprecated and will be removed. Use Y instead" > > Therefore, IMHO it appears like an API break. It is an API break. But LilyPond explicitly does not guarantee API compatibility between development versions. Just because it *often* works to run existing code on a new version without converting it does not mean you should expect it to work reliably. The assumption should be that whenever you run code on a new LilyPond development version, you may need to run convert-ly first. In this case, doing so would fully handle the API change. My personal recollection is that such changes have occurred at least once in every stable release cycle since I started using Lilypond on 2.12. And depending how much of LilyPond's API your code touches, they may occur much more often than that between development versions. I'm not sure I understand what is objectionable about a change in a development release that is fully handled by running convert-ly. Convert-ly is the primary tool LilyPond uses to manage API changes across versions. Transitional periods of cross-compatibility I believe are the exception, and mainly have been used for changes that aren't reliably handled by convert-ly. Lastly, Paolo, unless your code is a library that specifically needs to be agnostic to LilyPond version and support multiple versions, you should simply update your code to use an exact rational rather than make-moment. There is no need to include version checking logic in a file that you will only ever compile on one version of LilyPond. On Sat, Feb 8, 2025 at 7:45 PM Paolo Prete <paolopr...@gmail.com> wrote: > On Sun, Feb 9, 2025 at 1:20 AM Valentin Petzel <valen...@petzel.at> wrote: > > > > Hello Saul, > > > > > I don't want to speak for Dan, but I believe the objective is to get > user > > > code moved over to actually using exact rationals rather than moments > for > > > these properties, not just to allow the use of exact rationals in > addition > > > to moments. > > > > This is not what I talked about. My point is: A deprecated property you’d > > usually get when an interface has been considered as not optimal and is > > changed, but you give the user time to adjust, allowing the old > interface to > > still be used. This is not what is happening here. Here a new interface > is > > introduced (namely `proportionalNotationDurationAsMoment`) as deprecated > > property. Essentially this is telling the user: Here is a new feature, > but you > > should not actually use it, because it has been considered bad and will > be > > removed in a future release. > > > > Hello Valentin, > > I totally agree with you. And I add an observation: if an API is > deprecated, it should be clear to the user that it is actually > deprecated. > This is not the case. In fact, the raised warning says: > > "warning: the property 'proportionalNotationDuration' must be of type > 'non-negative exact rational or +inf.0', ignoring invalid value '#<Mom" > > ...while a proper warning to a deprecated function should be something > like: > "X is deprecated and will be removed. Use Y instead" > > Therefore, IMHO it appears like an API break. > I also highlight that it's the first time that I encountered something > like that since 2.19.84 (and I'm talking about code that uses the > LilyPond API extensively and intensively) > > I hope this can be reviewed and fixed in future releases. Meanwhile, I > can only add your workaround to my code. > > Cheers, > Paolo >
