Am Sa., 3. Dez. 2022 um 16:56 Uhr schrieb Jean Abou Samra <j...@abou-samra.fr>: > > 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?
It catches what you describe below. Call me a perfectionist, applying it to my custom codings. > > 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. > > > 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. Yep. > "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. Agreed. > 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. I will not object to the examples you mentioned. Alas, if -dcheck-internal-types detects something in my custom code, I feel the need to fix. Feels not clean otherwise. But that's probably only me... Best, Harm