On 10/8/20 11:04 PM, Alexandre Torres Porres wrote:
But I see that overriding it is not really dangerous in any way to Pd, at least I never had any issue.
it *can* be very dangerous. that is, you can completely brick Pd by overriding the right (or wrong) messages without providing sane alternatives.
an anecdote (that goes without "completely bricking" Pd) would be zexy's [pack] reimplementation (that doesn't do any type-enforcement), which used to happily override Pd's internal [pack] object (and as you know this is done by overriding the "pack" message of the objectmaker) - until this caused so much stir among the comunity that i had to revert the overriding (and you can now use the objects as [zexy/pack]).
now overriding a method to the objectmaker might break a single object. overriding a method to canvas might break patching.
having said that: overriding methods to canvas is a powerful tool to extend the patching capabilities of Pd itself.
oh btw: when you override a canvas method, you should have a plan to deal with overrides of the same method from other libraries. (and probably document that plan).
hamdsrt IOhannes