Le 03/12/2022 à 15:41, Thomas Morley a écrit :
Granted, if I use -dcheck-internal-types I mostly wear my developer hat. But sometimes I use it even for huge custom codings as part of debugging processes.
Why? What does it catch? In my view, warnings about a property being set on a grob that has no interface for it are nothing you need to care about as a user. This check merely helps ensuring that the IR remains complete when developers add features. I see no reason why it would be bad to set a property on a grob even if it doesn't have an interface declaring this property, if you set another property in this grob to something that will read it. For example, it's a common pattern to set stencil to #ly:text-interface::print and text to some markup, even on grobs that don't have text-interface. That's fine. On the other hand, if you change the stencil default for a given grob to #ly:text-interface::print in the source, you shouldn't forget to add text-interface to that grob. The other thing check-internal-types catches is callbacks returning a value of the wrong type, but I have never encountered this case AFAIR.
That said, we not only want to attract new users but new developers, too. Some of them may not be experienced programmers but musicians with some interest in coding (like me). Playing hide and seek with them may not be appreciated... We could place the info about -dhelp-internal in CG, but that would spread "help-infos" over two manuals. Thus I prefer my suggestion above.
Consider me indifferent.
Also, hiding internal things from mere users would arguable lead to a very small IR. We could just delete all internal grob and context properties. Which would be a very bad thing, if I think back how often I used them...
I view internal properties and internal options differently. LilyPond has a blurry line between users and developers. "Internal" for properties draws a line between advanced users and other users. Internal properties are thing that you can use if you know how to use them from Scheme and (like many Scheme things) accept the lesser degree of stability that you can expect from them. In contrast, for me, the options currently listed as "internal" really only make sense if you are a contributor working on the source, e.g., debug-gc-assert-parsed-dead catches low-level garbage collection problems, debug-parser is only useful if you know your way around the Bison / C++ parser, etc. Jean
OpenPGP_signature
Description: OpenPGP digital signature
