Type-Problem

[negaH]

Hm, das wäre mir absolut neu. Mich interessiert als Refernez nur das was die RTTI und somit der Compiler kann. In TypInfo.pas kann man sehr wohl lesen, als verwendeter realer Source!!, das eine Property auch virtuelle Getter/Setter haben kann.

Das spielt aber auch keine Rolle wenn es nicht so wäre. Dann ändern wir es so um das die Getter/Stetter statisch sind und intern als Dispatcher an 2 virtuelle Methoden weiterreichen.

Mich würde aber mal interessieren WO du das in der OH gelesen haben willst. Weil es dort nicht explizit steht und nur Beispiele mit statischen Methoden drinenstehen, heist dies noch lange nicht das es nicht geht. Ich programmiere seit es Delphi gibt (genauer seit BP4.0) und eine Setter/Getter Methode konnte schon immer statisch oder virtuell aber nicht dynamisch und somit ergo auch keine Nachrichtenmethode eg. als message deklariert sein. Sie darf sogar eine abstrakte Methode sein, und damit eben auch virtuell (abstrakte statische Methoden machen keinen Sinn).

Aus Sicht der Logik ist es auch sinnvoll, wenn man schon überschreibbare Methoden kennt, die Setter/Getter Methoden, die ja wiederum nur ein weiteres Qualitätsmerkmal der OOP umsetzen -> Properties, ebenfalls virtualisieren zu können. Warum sollten gerade auf die neueren Properties nicht die Regeln der OOP gelten ? (das wäre ein unlogischer Schritt von Borland gewesen den ich wohl am meisten kritisieren würde). Das man die Getter/Setter nicht dynamisch deklarieren kann ist eine Frage von Effizienz im Code. Sie wären unnötig langsam und brächten keinen Vorteil da man zu 99.99% der Zeit eine Property mit Getter/Setter Methoden sofort implementiert, statt mit dem Ziele sie über dynamische Methoden erst viel später durchimplementieren zu wollen. Hier zählt also der Kompromis von Aufwand und Nutzen der gegen dynamsiche Setter/Getter spricht. Der Sinn einer dynamsichen Methode besteht in der OOP darin das der Initial Entwickler einen Schnittstellenrumpf vorgeben kann ohne diese real implementieren zu müssen. Im Falle der Properties sind dynmische Methoden absolut sinnfrei, bzw. zu 99.9% sinnfrei
Das man dabei aber diese Methoden nicht als Messagemethoden deklarieren kann ist ebenfalls sinnvoll da sie mit einem Messaging nichts zu tuen haben. Davon abgesehen sind Messagemethoden eng verknüpft mit den dynamischen Methoden, infakt es sind dynamische Methoden mit explizierter Angabe der Slotnummer der DMT im Source (früher in BP konnte man die Slotnummer auch bei normalen dynamsichen Methoden vorgeben, heute geht dies nicht mehr, schade). Ergo: da dynamische Setter/Getter nicht gehen, können auch Messagemethoden nicht funktionieren.

Wie man sieht: die Regeln der OOP und wie die Borlanianer die VCL konstruiert haben unterwerfen sich zwingender Logik. Einer Logik die man selber nachvollziehen kann und mit der wir quasi schon erraten können was in der VCL geht oder nicht geht.

Ich schlage bei sowas immer vor: einfach selber mal ausprobieren statt sich einfach auf Meinungen Andere zu verlassen (davon gibts nämlich ne Menge Pseudowissen).

Gruß Hagen