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 only understood your suggestion at a very high level. Would you > revamp the list of properties in define-context-properties to allow > specifying the getters and setters per property? use alists like in > define-grobs?
Since the compatibility properties are just for compatibility and would not be used by LilyPond itself, access to them can be checked in the failure paths since performance is of secondary consideration. I'd use independent hashtables (probably as object properties on the symbols, using make-object-property) for getting and setting procedures. So I'd probably not give them a translation-type? property in order not to give generic routines any ideas. When you try setting or accessing them individually, this will work. But when you are asking questions about them, I'd rather tell the truth: "those properties aren't real". I'd probably bring them into existence with something like (define-compatibility-property 'baseMoment 'beatBase ly:moment? ly:moment-main ly:make-moment) and that will create the setter/getter procedures and register them for baseMoment. At some point of time, things like versioning and documentation may be added. Since the details are LilyPond internals, there is no need for a public interface. -- David Kastrup
