Webinar FreeAndNil

[Mavarik]

ROFL...

Kaum hatte Jim McKeeth das Thema im MVP Channel gepostet, ging die Diskussion schon los...

Keine Ahnung ob das Webinar jemanden etas bringt, aber wer sehen will, wie unterschiedlich die Meinungen unter den MVP's sind ist eingeladen...

Wird sicherlich lustig...

Grüsse

Mavarik

[Rollo62]

Zitat von Neutral General:

Ich seh das jetzt nicht so dass sich hier Leute aufreiben.

Oh doch, das ist anscheinend sowas wie eine Religionszugehörigkeit, nur Himmel und Hölle, sonst gibt es nichts dazwischen

[himitsu]

Zitat von Sinspin:

Als Delphianer räumt man ordentlich weg, was man hingeräumt hat.

⇘ *hust*

[freimatz]

Na ja dein Footer himitsu ...
Wenn Delphianer wirklich so sind. Schade dass man Kollegen hat die keine Delphiander sind aber Sourcecode in Delphi machen

[dummzeuch]

Zitat von Rollo62:

Ich seh das jetzt nicht so dass sich hier Leute aufreiben.

Siehe englische DP.

Zitat von Neutral General:

Oh doch, das ist anscheinend sowas wie eine Religionszugehörigkeit, nur Himmel und Hölle, sonst gibt es nichts dazwischen

Schlimmer noch als Himmel und Hölle eher wie vi vs. emacs.

[jaenicke]

Zitat von Rollo62:

Oh doch, das ist anscheinend sowas wie eine Religionszugehörigkeit, nur Himmel und Hölle, sonst gibt es nichts dazwischen

Solange man seine Meinung dazu auch begründen kann...
Ich finde, dass es sowohl Anwendungsfälle gibt, an denen FreeAndNil sehr viel Sinn macht, als auch solche, bei denen es keinen / wenig Sinn macht.

[Sinspin]

Zitat von dummzeuch:

Schlimmer noch als Himmel und Hölle eher wie vi vs. emacs.

Wahrlich!
Es ist also eine Sünde einfach FreeAndNil zu verwenden anstatt ordentlich zu programmieren und sicherzustellen das man nicht auf Objektreferenzen zugreift deren Objekte schon freigegeben sind.
So ganz sachte verstehen ich den Salat! Verwender von FAN sind also zu faul um ordentlich zu programmieren. Das ist jedenfalls die Meinung der FAN Gegner/Verweigerer.

Das macht mich Sprachlos. FAN hat den Vorteil das ich gegenchecken kann ob das Objekt weg ist. Ich kann also Objekte freigeben, und deren Referenzzustand "freigegeben" als Schalter verwenden.
Ich sehe mich dadurch nicht als Faul, sondern als Gewissenhaft an.

[himitsu]

Nja, im Notfall kann man immer FreeAndNil machen, was nahezu nie verkehrt ist.
Während bei einem .Free das nötige Zurücksetzen der Variable eventuell fehlen könnte. (z.B. für nachfolgende if-Assigned)

Und

Delphi-Quellcode:

x.Free;
x := nil;

könnte zwar richtig sein, aber wenn es im Free knallt, dann würde das NIL nicht mehr ausgeführt.

Zu

Delphi-Quellcode:

try
  x.Free;
finally
  x := nil;
end;

hat man oft keine Lust, was man aber mit FreeAndNil (eigentlikch NilAndFree) viel "einfacher" haben würde.




Und über ein Property oder ein Function-Result zu Löschen, da geht nur Free.
Für FreeAndNil müsste man es erst in eine Variable umkopieren.
(aber nur sinnvoll, wenn sich das Objekt da drüben auch selbst deregistriert/entfernt)




Krank / unverständlich empfinde ich aber, dass man Assigned bei Property/Result nicht direkt nutzen kann.
Wieso eigentlich nicht? (ein <>NIL als Ersatz ginge zwar, aber ist schon bissl inkonsistent, wenn sonst überall anders mit Assigned)

[Uwe Raabe]

Zitat von Sinspin:

Verwender von FAN sind also zu faul um ordentlich zu programmieren.

Ich denke, das Argument ist eher: Wenn du nicht sicher bist, ob die freigegebene Variable danach noch benutz wird, liegt ein Defekt in der Architektur vor, und den sollte man erst beheben. Das FreeAndNil kann dann zu Debug-Zwecken verwendet werden, wobei man dann an anderer Stelle nicht einfach auf nil prüft und gegebenenfalls nichts macht, sondern dann eine Exception wird (die ohne Prüfung auch kommen würde). Aber das ist manchmal schon arg akademisch.

[Rollo62]

Von den ganzen Pro-Argumenten finde ich das Proaktiv-In-Der-Zukunft Argument eigentlich am Schönsten:

In einer Basis-Klasse, die mal abgeleitet werden könnte, hilft FAN im Destruktur den Zugriff auf interne Felder abzusichern,
falls die Klasse zufällig mal abgeleitet wird und dabei jemand anderes diese falsch benutzt und versucht nach Destroy drauf zuzugreifen.
So oder so ähnlich.

Ist schön vorrausschauend gedacht, gefällt mir, aber ich fürchte es bleibt dabei:
Man braucht es eigentlich nicht wirklich wenn man das Klassen-Design gut ausgelegt hat.