With und Klassenmethoden

[idefix2]

With ist BÖSE
Klassenmethoden sind GUT

Jede Klassenmethode ist aber ein implizites with.

Könnte mir jemand diesen Widerspruch auflösen? Die Argumente gegen with sind mir bekannt. Sie gelten aber doch beim impliziten with einer Klassenmethode nicht weniger als bei jedem normalen with.

[uligerhardt]

Zitat:

Zitat von idefix2 (Beitrag 1312249)

Könnte mir jemand diesen Widerspruch auflösen? Die Argumente gegen with sind mir bekannt. Sie gelten aber doch beim impliziten with einer Klassenmethode nicht weniger als bei jedem normalen with.

Ja, aber nur in der Implementation der Klasse, nicht bei deren Verwendung. Also weniger Möglichkeiten für Überraschungen, und die auch nur für den Autoren der Klasse, der ja weiß, was er tut. :mrgreen:

[Sir Rufo]

Die Verwendung von

Delphi-Quellcode:

with

ist genau deswegen böse weil es schon ein implizites

Delphi-Quellcode:

with

in Methoden gibt.

In einer Methode ist der

Delphi-Quellcode:

Self

Kontext (Instanz oder Typ) klar definiert. Kommt nun ein weiterer (oder sogar mehrere) hinzu wird es unübersichtlich.

Und es ist einfach nur böse, weil man damit böse Überraschungen erleben kann. Wenn einem das egal ist, einfach verwenden. Kommt es zu Fehlern, aufgrund der Verwendung, sollte man deswegen hier bloss nicht fragen, denn der Hohn und Spott ist dir - zurecht - gewiss ;)

[EWeiss]

Zitat:

Kommt es zu Fehlern, aufgrund der Verwendung, sollte man deswegen hier bloss nicht fragen, denn der Hohn und Spott ist dir - zurecht - gewiss

Ich verwende kein With aber habe festgestellt das es Probleme mit dem IntelliSense sowie mit dem ToolTip beim debuggen gibt.
Andere Probleme wie hier aufgeführt sind mir jedoch noch nicht untergekommen.

Es erschwert lediglich die Visualisierung wenn man genau innerhalb eines Withblocks einen Fehler überprüfen will.

gruss

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1312252)

Andere Probleme wie hier aufgeführt sind mir jedoch noch nicht untergekommen.

Klassisches Beispiel: Als in einer Delphi-Version das TRect dann die Eigenschaften Width und Height bekam, erzeugten reihenweise Konstrukte wie

Delphi-Quellcode:

with myRect do begin
  Bottom := Left + Width;
  Right := Top + Height;
end;

zur Laufzeit ein falsches Verhalten. Vorher bezogen sich Width und Height noch auf den äußeren Scope - jetzt gibt es sie plötzlich auch im inneren. Der Compiler blieb davon natürlich ganz unbeeindruckt.

Solche Dinge können natürlich auch ohne with passieren, with ist aber vermeidbar.

Übrigens gibt es statische Sourcecode-Analyse-Tools, die sowas erkennen.

[EWeiss]

Ich denke es liegt daran das vor Bottom und Right kein Punkt '.' behandelt wird
Deshalb geht auch kein IntelliSense mehr und bei der Auswertung beim Debuggen wird der Tooltip nicht angezeigt.

IN VB geht es so..

Code:

with myRect
   .Bottom = .Left + Width;
   .Right = .Top + Height;
end with

Es besteht eine Verbindung zu myRect über den Punkt!
Design Fehler in Delphi?

gruss

[idefix2]

Zitat:

Zitat von Sir Rufo (Beitrag 1312251)

Die Verwendung von

Delphi-Quellcode:

with

ist genau deswegen böse weil es schon ein implizites

Delphi-Quellcode:

with

in Methoden gibt.

Die Argumentation ist allerdings wirklich verblüffend. Weil mein Bäcker Semmeln verkauft, sollte er endlich aufhören, Kornweckerl zu backen. :evil:

Zitat:

Zitat von Sir Rufo (Beitrag 1312251)

In einer Methode ist der

Delphi-Quellcode:

Self

Kontext (Instanz oder Typ) klar definiert. Kommt nun ein weiterer (oder sogar mehrere) hinzu wird es unübersichtlich.

und bei einem with ist der Kontext nicht klar definiert????


Probleme, wenn bei einer Klasse, die man verwendet, in einer späteren Version Dinge geändert werden, sind tatsächlich eine mögliche Fehlerquelle - wobei ich allerdings meinen würde, dass derartige Probleme extrem selten sein dürften, und dass mit derartigen Änderungen meist auch Änderungen im Verhalten von Klassen einhergehen werden, die in allen möglichen anderen Hinsichten eher Probleme machen werden.
Und es wäre ja auch leicht realisierbar, eine entsprechende Compilerwarnung auszugeben, wenn das Feld eines Records in einer with-Anweisung eine andere Variable "verdeckt" (wenn die Variable im with-Block angesprochen wird).

Schön wäre es meiner Meinung nach, wenn irgendwann in der Sprache eine erweiterung installiert würde, die es ermöglichen würde, etwas auf die Art von

Code:

with Feld[i+7*j].x[k] NAME F do
   F.a:=F.b+F.c

zu schreiben. Damit wären dann auch alle potentiellen Probleme erledigt - und aus diesem Beispiel ist auch ersichtlich, dass es durchaus Situationen gibt, wo with ein sehr nützliches Konstrukt ist.

[Sir Rufo]

Was ist an dem Beispiel von Uwe so unverständlich? :gruebel:

Nochmal, bei der Verwendung von

Delphi-Quellcode:

with

in einer Methode kann man eben nicht sicher sagen, worauf sich dort der Zugriff bezieht. Für den Moment mag das klar sein, aber wie sieht es in der Zukunft aus? Und wir sprechen hier nicht nur von den Klassen, die von Delphi selber kommen, sondern auch - oder gerade da - bei den Klassen, die man selber schreibt. Die sind doch nicht in Stein gemeißelt und können sich ändern.

Wenn ich jetzt bei jeder Änderung (neue Eigenschaft, Methode) immer den gesamten Code im Blick haben muss, ob da nicht irgendwo ein

Delphi-Quellcode:

with

verwendet wird und der Code auf einmal völlig anders reagiert. Die Anwendung kompiliert aber liefert nur Grütze. Jetzt kann man anfangen und alle Stellen heraussuchen, wo so ein

Delphi-Quellcode:

with

verwendet wurde, und sich jeden Code genau anschauen muss, um den korrekten Bezug wieder zu bekommen.

Spätestens nach dieser Erfahrung erklärt man

Delphi-Quellcode:

with

für böse und droht mit Teeren und Federn wenn irgendwer diesen Unfug wieder in den Code hineinbringt.

Ich vermisse das

Delphi-Quellcode:

with

nicht und brauche da auch keine Erweiterung.

Delphi-Quellcode:

var 
  F:TFoo;
begin
  ...
  F := Feld[i+7*j].x[k];
  F.a:=F.b+F.c;
end;

[Dejan Vu]

'with' ist für Tippfaule. Wer es in einfachen Konstrukten verwendet, würde von mir weder geteert noch gefedert. Beispiel:

Delphi-Quellcode:

With Combobox do 
  SelectedIndex := Item.IndexOf(Text);

Da wird man wohl schwerlich etwas erweitern, sodass es unübersichtlich oder der Scope unklar ist/wird. Außerdem programmieren im Team keine Kleinkinder.

Gabeln sind übrigens auch böse, weil man sich und Andere damit verletzen kann und beim Suppeessen verhungern würde. :roll: Die Konsequenz? In den meisten Kulturkreisen wird darauf verzichtet (hat zwar auch andere Gründe, aber egal, passt jetzt nicht :stupid:).

Und das wiederum bedeutet für unser 'With': Es ist in vielen Programmiererkreisen schlichtweg überflüssig. Und natürlich ist es nebenbei auch verpönt. Aber das sollte nicht der Grund für das Vermeiden dieses Wurmfortsatzes sein. Man braucht es einfach nicht, und wenn man es braucht, kann man es eigentlich immer auch eleganter lösen.

[idefix2]

Das Beispiel von Uwe ist schon klar, aber erstens ist eine eher seltene Ausnahme, und wäre durch eine einfache Compilerwarnung, dass im Bereich des With durch ein Feld der angegebenen Struktur eine andere Variable verdeckt wird, leicht aus der Welt zu schaffen, wenn Emba das einfach machen würde (ausser bei den Leuten, die in ihrem Code Dutzende Compilerwarnungen produzieren und sich nicht darum kümmern - aber die haben dann auch gravierendere Probleme).

Ebenso wäre eine Syntaxerweiterung auf die Art, wie ich sie vorgeschlagen habe, dafür eine Lösung. Natürlich kann man sich mit lokalen Variablen behelfen, aber das ist m.E. im Vergleich zum with-Konstrukt schwerfällig. Genauso, wie wenn man statt Klammern in Ausdrücken die Teilausdrücke auf lokale Variable zwischenspeichern würde.

Zitat:

Man braucht es einfach nicht, und wenn man es braucht, kann man es eigentlich immer auch eleganter lösen.

Nein, man kann es eigentlich immer auch umständlicher lösen.