With und Klassenmethoden

[Uwe Raabe]

Zitat von EWeiss:

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

[Bjoerk]

Zitat von Uwe Raabe:

Zitat von EWeiss:

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 von 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.

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

Zitat von idefix2:

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

[jaenicke]

Zitat von EWeiss:

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 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 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 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.

[Uwe Raabe]

Zitat von Bjoerk:

Uwe, kannst du ein Sourcecode-Analyse-Tool empfehlen? Ich würde den Code gerne diesbezüglich mal überarbeiten.

Ich verwende dazu den Pascal Analyzer.

Zitat von Dejan Vu:

Der Parser läuft schneller, weil er weniger zu parsen hat.

Um mal auf die ursprüngliche Intention von with und die damaligen Einschränkungen hinzuweisen:

Zitat von Pascal User Manual and Report (1975):

The above notation can be a bit tedious, and the user may wish to abbreviate it using the with statement. The with clause effectively opens the scope containing the field identifiers of the specified record variable, so that the field identifiers may occur as variable identifiers. (Thereby providing an opportunity for the compiler to optimize the qualified statement.)

...

No assignments may be made by the qualified statement to any elements of the record variable list. That is, given:

with r do S

r must not contain any variables subject to change by S.

Vereinfachte Schreibweise war wohl nur ein netter Nebeneffekt. Die Optimierung des Compilers war damals halt viel wichtiger. Und Ändern des Records innerhalb with ging auch nicht.