With und Klassenmethoden

[p80286]

Zitat:

Zitat von Dejan Vu (Beitrag 1312269)

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

Da "einfach" doch sehr relativ ist, meide ich With wie der Teufel das Weihwasser. Lieber 10 Zeichen mehr tippen, als stundenlang mit dem Debugger die falschen Werte kontrollieren.
Wer's trotzdem verwendet muß halt damit leben, darf sich dann hinterher aber nicht beschweren.

Gruß
K-H

P.S.
mit relativen Dateinamen ist genau das gleiche....

[Bjoerk]

Zitat:

Zitat von Uwe Raabe (Beitrag 1312253)

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.

Genau dieses Problem ist bei PowerPdf. Dort verwendet der Autor zienlich exzessiv with MyRect. Deshalb läuft der Code auch nicht mehr ab der Delphiversion, ab der TRect ein Width und Height hat (glaube XE). Uwe, kannst du ein Sourcecode-Analyse-Tool empfehlen? Ich würde den Code gerne diesbezüglich mal überarbeiten.

[EWeiss]

Wäre niemals passiert hätte man es Design Technisch korrekt gelöst so wie in VB halt auch.

Code:

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

Da gehört ein Punkt vor.

Ist also Width und Height ein Teil von myRect(TRect)
dann wäre Width die weite und .Width die der ermittelten TRect Weite.

Aber Delphi war immer schon etwas extravagant und musste sich vom Syntax(Script) unbedingt von VB unterscheiden.

gruss

[jaenicke]

Zitat:

Zitat von EWeiss (Beitrag 1312282)

Wäre niemals passiert hätte man es Design Technisch korrekt gelöst so wie in VB halt auch.

Code:

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

Da gehört ein Punkt vor.

Das ist ja noch schlimmer. :shock: Nur durch einen kleinen Punkt die Bedeutung ändern ist ja erst recht der Tod für leichte Codelesbarkeit.

Zitat:

Zitat von idefix2 (Beitrag 1312261)

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.

Wenn mein Code so geschrieben wäre, dass ich das brauchen würde, würde ich vielleicht auch with verwenden.

Aber da meine Methoden so kurz sind, dass ich nicht scrollen muss um zur Variablendeklaration zu gelangen und auch der Scope kein Problem ist, sehe ich ausschließlich Nachteile in einer solchen Konstruktion.
Wo liegt denn der Vorteil gegenüber einer einfachen lokalen Variable?!?

[EWeiss]

Zitat:

Das ist ja noch schlimmer. Nur durch einen kleinen Punkt die Bedeutung ändern ist ja erst recht der Tod für leichte Codelesbarkeit.

Dir ist aber schon klar das der Punkt den Zugriff auf das IntelliSense ermöglicht?
Gebe doch mal direkt hinter myRect den Punkt ein.

Vielleicht verstehst du dann was ich meine.
Mir käme dann niemals in den Sinn hier .Width (aus dem Aufgeklappten IntelliSense Menu) zu verwenden wenn ich die Weite der Form verwenden möchte.

Verstehe nicht was da schlimmer sein soll.

gruss

[Luckie]

Zitat:

Zitat von Dejan Vu (Beitrag 1312269)

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

Und warum dann nicht gleich ganz abgewöhnen? Und was sind einfache Konstrukte? Das ist doch sehr schwammig formuliert und für jeden bedeutet "einfach" was anderes. Zumal der Quelltext in sich konsistenter wird, wenn man es generell vermeidet und nicht nur bei komplexen Konstrukten.

[jaenicke]

Zitat:

Zitat von EWeiss (Beitrag 1312286)

Dir ist aber schon klar das der Punkt den Zugriff auf das IntelliSense ermöglicht?

Dafür brauche ich keinen Punkt, weil ich natürlich kein with verwende und es deshalb ohnehin funktioniert.

[Sir Rufo]

Selbst der Punkt hilft nicht, denn in Delphi kann man sich soviele Typen wie man nur will in den Scope holen.

Und eine Warnung des Compilers hilft auch nicht wirklich weiter wenn das Kind erstmal in den Brunnen gefallen ist. Ich muss erst den ganzen Verhau wieder auseinanderfummeln um die gewünschte Funktion wieder auf die Reihe zu bekommen.

Gegeben folgende Basis-Klasse:

Delphi-Quellcode:

type
  TMyClass = class abstract
  public
    procedure DoSomethingWith( FooBar: TFooBar ); virtual; abstract;
  end;

und diese einmal schlecht mit

Delphi-Quellcode:

with

:

Delphi-Quellcode:

type
  TMyBad = class( TMyClass )
  public
    procedure DoSomethingWith( FooBar: TFooBar ); override;
  end;

procedure TMyBad.DoSomethingWith( FooBar: TFooBar );
begin
  with FooBar, FooBar.Bar, FooBar.Bar.Foo do
    begin
      FooMethod( ); // eine Methode von Foo
      BarMethod( ); // eine Methode von Bar
      FooBarMethod( ); // eine Methode von FooBar

      Special( ); // welches Special wird denn nun ausgeführt?
    end;
end;

Die IDE zeigt mir zwar an, von welcher Klasse die Special-Methode aufgerufen wird, aber ist das immer noch die Methode, die eigentlich angedacht war? Sind in der Zwischenzeit Änderungen an den Klassen erfolgt? Man kann es nicht mehr sagen ... hoffentlich erinnert man sich, oder man dokumentiert es ... äh, also mehr Tipparbeit - die wir uns durch das

Delphi-Quellcode:

with

doch gerade ersparen wollten ...

Gut, ein anderer Ansatz wäre das hier

Delphi-Quellcode:

type
  TMyGood = class( TMyClass )
  private
    procedure InternalDoSomething( FooBar: TFooBar; Bar: TBar; Foo: TFoo );
  public
    procedure DoSomethingWith( FooBar: TFooBar ); override;
  end;

procedure TMyGood.DoSomethingWith( FooBar: TFooBar );
begin
  InternalDoSomething( FooBar, FooBar.Bar, FooBar.Bar.Foo );
end;

procedure TMyGood.InternalDoSomething( FooBar: TFooBar; Bar: TBar; Foo: TFoo );
begin
  Foo.FooMethod( );
  Bar.BarMethod( );
  FooBar.FooBarMethod( );
  FooBar.Special( ); // aha, DAS Special soll ausgeführt werden!
end;

Wegen mir soll jeder sein

Delphi-Quellcode:

with

verwenden. Ich brauche es nicht aus dem gleichen Grund, wie es jaenicke schon beschreiben hat:

Kurze knackige Methoden.

[stoxx]

with ist nicht typsicher, deswegen verwende ich es nicht.
Heute noch funktionierend, morgen bei einer Variablenumbennung benutzt man mit with nicht mehr die innere Variable, sondern irgendeine eine ganz andere.
With gefährdet für mich das Ziel einer unbedingten Verlässlichkeit einmal entwickelter und getesteter Quelltexte.
Und wenn ich einen Fehler mache, dann möchte ich in sovielen Fällen wie möglich vom Compiler gewarnt werden.
Genau das verhindert with.

Ich habe in fremden Quelltexten schon genau solche Bugs finden und ausbessern müssen, die genau so entstanden sind.
Falls noch nicht existent, lege ich stattdessen immer manuell eine Variable der Klasse / des Records an und schreibe immer mindestens:

anstatt

Delphi-Quellcode:

with tiefe.Klassenstruktur.irgendwo.drin do begin
  value1 := 5;
  value2 := 6;
  value3 := 7;
end;

schreibe ich:

obj := tiefe.Klassenstruktur.irgendwo.drin;
obj.value1 := 5;
obj.value2 := 6;
obj.value3 := 7;

das ist nicht soviel umständlicher und man bekommt sogar noch den Vorteil, dass einem der Compiler immer helfen kann.

[Sunec]

Also mein Programmierlehrer hatte damals immer zu with geraten :-D

Nachdem ich mir das ganze hier durchgelesen habe werde ich es wohl eher nicht mehr benutzen.