On Sun, Feb 9, 2025 at 2:01 AM Saul Tobin <saul.james.to...@gmail.com> wrote:
>>
>> 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.
>
Sorry but I disagree. It can easily happen, as it happened to me, that
a library in a project is updated and only later the code that uses
that library is updated. Consequently it is normal routine to write to
the user a message like the one I mentioned in these cases ("X is
deprecated and will be removed. Use Y instead"). It is not my idea but
it is really a very common practice.
>
> 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.
>
My project is exactly aimed at being agnostic of the LilyPond version
and supports multiple LilyPonds:
https://github.com/paopre/Spontini
For this reason I asked the question and because of the problem
reported in this thread I am forced to add the workaround that
Valentin pasted, while I could have left the code as it is and ignored
the appropriate warning
Cheers,
P
