Die Abschnitte public und published definieren die Schnittstelle für den Entwickler, der eine Komponente verwenden möchte. Der protected Abschnitt erweitert diese Schnittstelle für Entwickler, die von diese Klasse ableiten wollen. Eigentlich sollten auch spätere Versionen dieser Klasse immer mindestens die einmal veröffentlichten Properties und Methoden unterstützen.
Ok, das ist verständlich als reiner Anwender (auch wenn man Entwickler ist) der Komponente soll man gefälligst die Schnittstellen nutzen die vorgesehen sind. Das ist jetzt eben die Schwierigkeit und da ist es dann quasi vorbei mit der
OOP wenn man eben kein Zugriff auf notwendige Daten hat, weil nicht vorgesehen.
Wenn der Entwickler es für notwendig hält, kann sich im Abschnitt private dagegen von Version zu Version alles ändern.
Gut, dass es interne Variablen geben muss, die die innere Funktion Gewährleisten okee, aber dass es keine ordentliche Möglichkeit gibt auf funktionelle Variablen zu zugreifen deren Manipulation für eine Erweiterung notwendig sind nur weil der Komponentenersteller das "fälschlicherweise" als private deklariert hat. Wobei ich hier jetzt eigentlich keine Grundsatzdiskussion lostreten wollte. Die Komponente wie sie ist wurde einfach nicht so programmiert, dass sie mittels
OOP erweitert werden kann, fertig.
Im Prinzip ist ein Hack für den Zugriff auf private Felder immer nur für die Versionen gültig, für die er auch erstellt wurde. Eine Garantie für zukünftige Versionen kann es nicht geben.
Auf bekannte Änderungen in bestimmten Versionen kann man aber mit bedingter Kompillierung reagieren.
Dafür müsste man ja aber erstmal wissen, ob er noch funktioniert.