This has been mentioned before I think, but also applies to TMP versions of Unity UI code.
It is often difficult to extend UI classes with custom features due to the number of private variables and functions or non-virtual functions.
Allowing almost everything to be visible (protected not private, virtual) by a class that inherits may break some code rules (?) but allows for full customisation when wanted.
i.e. lets you customise drop down items - AddItem(…) is private in TMP_Dropdown - although CreateItem is virtual so half way ok
1 Like
As a workaround, you can modify downloaded source code of the package. On linux, it’s in ~/.config/unity3d/cache/packages/packages.unity.com/ I don’t know where are they on other OS, but I think it can be found using search and typing “packages.unity.com”.
Yes this is true. Full source being provided is good
I agree that would be cool not to have any ‘private’ keyword and to have every property and method ‘virtual’.
And the issue is even broader than that, in the games we create we should also avoid using private and make everything virtual when we intend the game to be moddable.
Unfortunately, I guess that habits aren’t that easy to lose (especially since these habits are usually very good ones).