Unterschied Sichtbarkeitsmodifikator 'Published' zu 'Public'

[Der schöne Günther]

Hallo-

Ich komme auf keinen grünen Zweig, wo im Jahr 2013 des Herrn sich noch ein Unterschied von published zu public verbirgt. Als Delphi anscheinend noch nur rudimentäre RTTI-Konzepte verfügte, musste man Member einer Klasse wohl explizit mit published kennzeichnen um mittels RTTI überhaupt darauf zugreifen zu können.

Die RAD-Hilfe (Stand: XE4) schreibt hierzu:

C++:

Zitat:

Das Schlüsselwort __published wurde zur Unterstützung der VCL hinzugefügt. Dieser öffentliche Member-Zugriffsspezifizierer entspricht dem public Spezifizierer, aber __published verfügt über vom Compiler erzeugte RTTI (Run-Time Type Identification, Identifikation von Typen zur Laufzeit). Das bedeutet, dass die __published Eigenschaften beim Entwurf im Objektinspektor erscheinen.

(Quelle)


Delphi:

Zitat:

Bei Klassen, die von TPersistent abgeleitet sind, werden in einem published-Abschnitt Eigenschaften und Ereignisse deklariert, die zur Entwurfszeit verfügbar sind. Ein published-Element hat dieselbe Sichtbarkeit wie ein public-Element, aber der Compiler erzeugt Laufzeittypinformationen für die published-Elemente. published-Eigenschaften erscheinen zur Entwurfszeit im Objektinspektor.

(Quelle)

Besonders im Delphi-Fall scheint das wieder etwas zu sein, was seit zehn Jahren dort steht und seitdem niemand mehr angefasst hat. Denn entweder liege ich komplett daneben, oder

• Ich komme mittels RTTI genauso auf die public-Elemente
• Kann ich mir im Objektinspektor auch alles mit beliebigem Sichtbarkeitsmodifikator anzeigen lassen

Möglicherweise irre ich mich in zwei Dingen:

• Mit Objektinspektor ist etwas vollkommen anderes gemeint als ich verstehe - Beispielsweise irgendetwas beim Debuggen?
• Mittels RTTI kann ich über published Member noch viel Mehr in Erfahrung bringen, als über schnöde public Member. Nur was?

Ich freue mich auf Erleuchtung :-)

[Daniel]

Wenn Du selbst eine Komponente schreibst und deren Eigenschaften im Objekt-Inspektor sehen (und verändern) möchtest, dann müssen diese im "published"-Bereich liegen. Nur dann werden sie auch automatisch vom Streaming-System erfasst und landen in der .DFM-Datei.

[Sir Rufo]

Auf die

Delphi-Quellcode:

published

Member kannst du mit System.TypInfo.GetPropValue bzw. System.TypInfo.SetPropValue etc. zugreifen.

Für die anderen Member benötigst du System.Rtti -> erweiterte RTTI

[Bernhard Geyer]

Es gibt die RTTI (Seit D1) und die extended RTTI (Seit D2009?)
Für die "normale" RTTI gelten die Aussagen noch. Extended RTTI kann man ja aktivieren/deaktivieren.

[Der schöne Günther]

Extended RTTI habe ich so oder so drin und abwärtskompatibel zu alten Delphi-Versionen muss es auch nicht sein, also macht das die Sache ja einfacher :-)

Zusammenfassend ist es also nur eine Sache die nötig ist, damit die Delphi-IDE weiß, was sie zur Serialisierung in die .DFM-Datei hernehmen muss? Wäre es heute auch noch gängige Praxis, in Delphi eine Klasse so aufzubauen, dass langlebige Eigenschaften published und laufzeitabhängige Dinge nicht published sind? :gruebel:

(Man merkt vielleicht, dass diese Frage hier nur ein Vorläufer für meine eigentliche ist - Ich mache mich gerade schlau, wie ich in Delphi eine Serialisierung von eigenen Objekten möglichst elegant und automatisiert über die Bühne bringe...)

[stahli]

... dafür sind Attribute noch ganz nützlich.
So kannst Du Felder oder Eigenschaften kennzeichnen, ob und wie sie serialisiert werden sollen.

[Lemmy]

Zitat:

Zitat von Der schöne Günther (Beitrag 1215900)

(Man merkt vielleicht, dass diese Frage hier nur ein Vorläufer für meine eigentliche ist - Ich mache mich gerade schlau, wie ich in Delphi eine Serialisierung von eigenen Objekten möglichst elegant und automatisiert über die Bühne bringe...)

kommt drauf an was du genau machen willst, die Du die Serialisierung steuern willst usw....

ich habe mit der alten RTTI und 2 Methoden mein Klassenmodell sehr simpel, schnell und zuverlässig serialisieren und deserialisieren können. Die neue RTTI habe ich nicht verwendet, weil nicht benötigt und zudem ist sie schlicht langsamer als TypInfo (oder zumindest war sie zu zeiten XE/XE2).

Ich fand es immer sehr angenehm die Properties zur Entwurfszeit schon dadurch unterscheiden zu können, was serialisiert (dann unter published) und was eben nicht gespeichert werden soll (public) zu trennen. Wüsste aber ehrlich gesagt nicht ob ich das heute noch immer so machen würde :-)

Um auf deine Frage antworten zu können: einen Königsweg gibt es nicht und elegant und automatisiert kannst Du das per neuer und auch alter RTTI machen...

Grüße

[Der schöne Günther]

Zitat:

Zitat von stahli (Beitrag 1215913)

... dafür sind Attribute noch ganz nützlich.

Faszinierend. Von deren Existenz wusste ich bislang nichts. Die ersten zwei Treffer der Suchmaschine meines Vertrauens zu "delphi attribute" sehen schon sehr vielversprechend aus, das geht eindeutig in die richtige Richtung :thumb:

Zitat:

Zitat von Lemmy (Beitrag 1215915)

Ich fand es immer sehr angenehm die Properties zur Entwurfszeit schon dadurch unterscheiden zu können, was serialisiert (dann unter published) und was eben nicht gespeichert werden soll (public) zu trennen.

Dem ersten Teil stimme ich voll zu, dem zweiten weniger. Entweder stehe ich heute auf dem Schlauch oder ich hätte es nicht gerne, Dinge voll sichtbar zu haben (published) zu haben, die ich am Objekt eigentlich nicht von außen geändert haben möchte. Aber das nur am Rande.

Zitat:

Zitat von Lemmy (Beitrag 1215915)

Um auf deine Frage antworten zu können: einen Königsweg gibt es nicht und elegant und automatisiert kannst Du das per neuer und auch alter RTTI machen...

Dein Tutorial mittels "alter" RTTI habe ich schon gesehen :-) Momentan schaue ich mir die DataSnap-Komponenten und ihre JSON-Methoden an, aber das führt hier zu weit. Im Verlaufe des Tages mache ich da wohl ein eigenes Thema draus.

[Lemmy]

Zitat:

Zitat von Der schöne Günther (Beitrag 1215920)

Zitat:

Zitat von Lemmy (Beitrag 1215915)

Ich fand es immer sehr angenehm die Properties zur Entwurfszeit schon dadurch unterscheiden zu können, was serialisiert (dann unter published) und was eben nicht gespeichert werden soll (public) zu trennen.

Dem ersten Teil stimme ich voll zu, dem zweiten weniger. Entweder stehe ich heute auf dem Schlauch oder ich hätte es nicht gerne, Dinge voll sichtbar zu haben (published) zu haben, die ich am Objekt eigentlich nicht von außen geändert haben möchte. Aber das nur am Rande.

hm... warum speichert man Dinge ab, die man dann nie mehr in das Objekt laden kann? Macht doch keinen Sinn oder verstehe ich dein Ansinnen falsch?

Zitat:

Zitat von Der schöne Günther (Beitrag 1215920)

Dein Tutorial mittels "alter" RTTI habe ich schon gesehen

freut mich, wenn das noch jemand ließt... :-)