TClientSocket auf Datenmodul

[Sir Rufo]

und warum nicht einfach

Delphi-Quellcode:

Procedure TMyDataModule.DataModuleCreate(Sender : TOBject);
Begin
  MyClientDataset := TClientDataset.Create( Self );
  MyClientDataset..... // Properties setzen
end;

Dann kümmert sich das DataModul selber um die Freigabe

Beobachtet habe ich das auch schon und als Workaround probier mal folgendes aus:

1. Ziehe auf ein Formular die gewünschte Komponente
2. Die Komponente von der Form auswählen und mit STRG-X ausschneiden
3. Auf das DatenModul wechseln und mit STRG-V dort einfügen
4. Alles speichern

Jetzt sollten auch alle nicht-visuellen Komponenten auswählbar sein

[Furtbichler]

Zitat von Sir Rufo:

und warum nicht einfach

Delphi-Quellcode:

Procedure TMyDataModule.DataModuleCreate(Sender : TOBject);
Begin
  MyClientDataset := TClientDataset.Create( Self );
  MyClientDataset..... // Properties setzen
end;

Dann kümmert sich das DataModul selber um die Freigabe

Das widerspricht dem Designtemplate: "Wer's anfordert, gibts wieder frei". Ansonsten haste Recht.

[Sir Rufo]

Zitat von Furtbichler:

Zitat von Sir Rufo:

und warum nicht einfach

Delphi-Quellcode:

Procedure TMyDataModule.DataModuleCreate(Sender : TOBject);
Begin
  MyClientDataset := TClientDataset.Create( Self );
  MyClientDataset..... // Properties setzen
end;

Dann kümmert sich das DataModul selber um die Freigabe

Das widerspricht dem Designtemplate: "Wer's anfordert, gibts wieder frei". Ansonsten haste Recht.

Hmmm, mal überlegen wer denn jetzt wer ist ... IMHO ist hier "wer" ja die Instanz von TMyDataModule.
Wenn ich also der erzeugten Instanz vom ClientDataSet als Owner die Instanz von TMyDataModule mitgebe, so ist das nicht nur möglich, sondern auch noch in jeder Hinsicht richtig.

Somit sehe ich es hier in diesem (speziellen) Fall keinen Widerspruch zum Designtemplate, denn der übergebene Owner ist auch derjenige, der es angefordert hat

[Furtbichler]

Es geht aus dem Code nicht hervor, das MyClientDataset ordentlich freigegeben wird. Um den Code zu verstehen, muss ich in fremden Code nachschauen, wobei sich hier Probleme ergeben:
* Habe ich den Quelltext? (hat nicht jeder)
* Existiert ein Manual? (ja ja, F1)
* Wird da wirklich etwas freigegeben? (hoffen wir mal)
Ich muss also ganz schöne Klimmzüge anstellen, um zu verifizieren, das das Objekt freigegeben wird. => Unnötige Arbeit => schlecht lesbar => schlecht wartbar.

Das sind nicht gerade Argumente für deine Version (aus Sicht der Lesbarkeit).

Von der Orthogonalität der verwendeten Klassen her hast Du natürlich Recht: "Das wird überall in der VCL so gemacht, der Designer machts auch, also mach ich es auch. Und das ist auch gut so". Ein versierter Leser des Codes, der vorher anderen VCL-Code gelesen hat, wird diese implizite (eigentlich: versteckte) Freigabe erkennen. Wir programmieren aber im Idealfall nicht für Gurus.

[Sir Rufo]

Zitat von Furtbichler:

Es geht aus dem Code nicht hervor, das MyClientDataset ordentlich freigegeben wird. Um den Code zu verstehen, muss ich in fremden Code nachschauen, wobei sich hier Probleme ergeben:
* Habe ich den Quelltext? (hat nicht jeder)
* Existiert ein Manual? (ja ja, F1)
* Wird da wirklich etwas freigegeben? (hoffen wir mal)
Ich muss also ganz schöne Klimmzüge anstellen, um zu verifizieren, das das Objekt freigegeben wird. => Unnötige Arbeit => schlecht lesbar => schlecht wartbar.

Eine wesentliche Eigenschaft der Klasse TComponent ist die Owner-Beziehung, die im Wesentlichen u.a. dafür sorgt, dass der Owner einer TComponent-Instanz die Freigabe veranlasst, wenn der Owner freigegeben wird.
Man könnte also fast behaupten, dass ein Großteil der Daseinsberechtigung von TComponent aus diese Owner-Beziehung besteht.
Die Klasse TComponent selbst ist eine der wesentlichen Basis-Komponenten der VCL.

Deiner Argumentation folgend und weitergedacht, dürfte ich auch keine TStrings benutzen, weil ich ja nicht weiß, ob die Strings wirklich gespeichert werden (ich müsste dort auch erst mal den Quelltext sichten, und wenn ich den nicht habe ...)
Eigentlich dürfte ich keine Komponenten verwenden ... alles selber programmieren.

Ein weiteres Kriterium, für die Angabe eines Owners, ist der einfachere Zugriff auf die Komponenten über das Components-Array des Owners.
Dieses funktioniert aber nur, wenn ich den Owner bei der Instanz-Erzeugung mit angebe.
Und wenn ich den Owner angebe, dann habe ich - as designed - die Verantwortung für die Freigabe delegiert, an den Owner.

Wer dieses dann im Code nicht versteht, der sollte sich auch den Gefallen tun und den Editor ganz schnell wieder schließen, denn es fehlen die existentiellen Grundlagen für die VCL.

@all: Wenn diese Diskussion hier nervt, dann nur Bescheid geben - wir führen dies dann per PN weiter

[Furtbichler]

Ich sagte ja bereits, das man das so schreiben kann, wenn man unterstellt, das der Leser die VCL und ihre Eigenheiten kennt.

Zitat von Sir Rufo:

Deiner Argumentation folgend und weitergedacht, dürfte ich auch keine TStrings benutzen, weil ich ja nicht weiß, ob die Strings wirklich gespeichert werden

Das ist nicht weitergedacht, sondern um-die-Ecke-gedacht, denn: Die Funktionalität einer Klasse ist etwas anderes als ihre Seiteneffekte. Und die Tatsache, das ein TComponent-Derivat vom Owner freigegeben wird, ist ein nicht im Code dokumentierter Seiteneffekt (ja gut'eh, Seiteneffekte sind vom Wesen her nicht dokumentiert).

Zitat:

...Wer dieses dann im Code nicht versteht, der sollte .. den Editor ganz schnell wieder schließen...

So kann man sich auch aus der Affäre ziehen.

So, wenn man die sinnvollen Argumente mal gegenüberstellt, dann ergibt sich das gleiche Bild wie eben (imho):
Einerseits (ohne Owner) eine bessere Lesbarkeit für Leute, die die VCL nicht in- und auswendig kennen (also mich z.B. ), andererseits eine im Design der VCL verankerte Verwendung (mit Angabe des Owners) mit praktischen Vorteilen.

Hier ist es imho blöd, das man entweder das eine, oder das andere bekommt, aber nicht beides. Obwohl....

Was passiert, wenn ich MyClientDataset freigebe? Sagt es dem Owner nicht: "Schmeiss mich aus deiner Liste raus"?

Dann könnte ich ja den Owner mit angeben und (wenn ich denn unbedingt will) das Objekt trotzdem explizit freigeben. Damit könnte man die Diskussion im Konsens schließen und sich wieder der Programmierung von diesem dusseligen Suchdingsda widmen, das sowieso keiner braucht. Wie hast Du das doch gleich genannt? "Gugl"?

[DeddyH]

Da man Workarounds ja IMO sowieso tunlichst kommentieren sollte kann man ja gleich dazu schreiben, wieso entweder kein Owner angegeben wurde oder keine explizite Freigabe erfolgt und ist somit aus dem Schneider

[Sir Rufo]

Ich sehe eben dieses Freigeben durch den Owner nicht als Seiteneffekt, sondern als Funktionalität - und eben eine Basis-Funktionalität an. Benutzt du keine Formulare, auf denen ein paar visuelle Komponenten platziert sind (TEdit, etc.)?
Wo ist da im Code dokumentiert, dass die überhaupt erzeugt werden, geschweige denn freigegeben?

Natürlich kann man eine Komponente auch wieder explizit freigeben, denn diese meldet ihrem Owner, dass sie sich jetzt mal vom Acker macht ... schön ist es nicht, aber es funktioniert.

Eigentlich gibt man den Owner an, wenn die Lebensdauer der Komponente vom Owner abhängen soll.
Und praktisch ist das in dem Falle auch, weil man sich einen Speicher (Liste) mit den Komponenten und die Freigabe-Orgie am Ende spart.
Das ist somit für faule Programmierer wie mich gemacht worden

Zitat von DeddyH:

Da man Workarounds ja IMO sowieso tunlichst kommentieren sollte kann man ja gleich dazu schreiben, wieso entweder kein Owner angegeben wurde oder keine explizite Freigabe erfolgt und ist somit aus dem Schneider

Ich habe ja schon einen Workaround angegeben, wo am Ende der normale RAD-Ansatz wieder funktioniert - Komponenten-Drauf-Klatschen