With und Klassenmethoden

[Sir Rufo]

Die Verwendung von with ist genau deswegen böse weil es schon ein implizites with in Methoden gibt.

In einer Methode ist der 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 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

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

[idefix2]

Zitat:

Und Ändern des Records innerhalb with ging auch nicht.

Ich denke, das dürfte ein Mißverständnis sein. Was hier gemeint sein dürfte und nach meiner Erinnerung die allererste Pascal Implementierung auf der CDC, auf der ich mein Studium begonnen habe, verboten hat, war eine Veränderung von Variablen, die zur Adressberechnug des Objekts benötigt worden sind.

Code:

with x[i] do
   begin
   i:=i+1
   ...
   end;

Diese Einschränkung ist allerdings zumindest in einer etwas späteren Version sehr bald gefallen. Man konnte im with Block dann auch Variable verändern, die für Berechnung der record Adresse benötigt wurden (sogar ohne dass das das Objekt des With verändert hätte). Beim Bearbeiten von Listen war dann absolut üblich

Code:

while p<>nil do
  with p^ do
    begin
    ... 
    p:=next;
    end;

Zitat von Dejan Vu:

Ich glaube, alle Vorteile von 'with' wurden zur Genüge erwähnt:

Zitat von Sir Rufo:

Haben wir immer so gemacht

Zitat von Luckie:

Habe ich so ... gelernt.

Zitat von Dejan Vu:

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

Andere gibt es nicht.

Ich finde es schade, dass sich Emba nicht dazu entschliessen kann, durch eine simple Erweiterung der Syntax die Schwachstellen des with zu eliminieren. Tatsächlich trägt with dazu bei, den Code optisch besser zu strukturieren und damit übersichtlich zu machen. Leider in der aktuellen Syntax mit gewissen Risken, die gegenüber dem Vorteil manchmal überwiegen.