Paul <address@hidden> writes:
1. Make those two procedures "define-public" so users can just use
them to define their own properties. This requires very minimal
change to LilyPond code, and is convenient for users since existing
functions will just work for accessing and setting their custom
properties (e.g. ly:grob-property).
The problem with the current implementation is that such additions are
not limited in scope and will persist beyond the currently processed
file.
2. Define a "custom-properties" grob property and a "customProperties"
context property (or whatever name) that each holds an alist of user
properties. This adds additional properties to LilyPond and is a
little more complex for the user to work with, but it provides
isolation from LilyPond's properties. (For example, users would only
have to worry about conflicts with other user-defined properties, not
conflicts with current or future LilyPond properties.)
This will not work with current code checks working with object
properties.
I'm interested in implementing this one way or another. Using the
same approach for grob and context properties would make sense.
Thoughts?
First you'd need to move is-grob? and its friends from the old "object
properties" interface to the new, function-calling one. That's an
incompatible change.
Then you'd need to use a session-local defining function for defining
those properties, one that restores the startup state after each
session.
Here is some stone-age patch where you can see how the first step would
look in Scheme (the C++ part would no longer apply since
lily_module_constant has been superseded by the lily-imports.{cc,hh}
files).
All previous such "extensions" dabbling in internals would stop working.
So would previous checks for these properties (it's conceivable to
redefine the old object property accessor functions as they are not
likely to be used outside of LilyPond and a bit of performance impact
for legacy use would be tolerable).