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.

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

[Luckie]

Zitat:

Zitat von Sunec (Beitrag 1312306)

Also mein Programmierlehrer hatte damals immer zu with geraten

Die Begründung wäre jetzt interessant.

[Sir Rufo]

Zitat:

Zitat von Luckie (Beitrag 1312309)

Zitat:

Zitat von Sunec (Beitrag 1312306)

Also mein Programmierlehrer hatte damals immer zu with geraten

Die Begründung wäre jetzt interessant.

Haben wir immer so gemacht :mrgreen:

[Luckie]

Habe ich so im 2 wöchigen Crashkurs in der Umschulung von Religionslehrer zum Informatiklehrer so gelernt. :mrgreen:

[Dejan Vu]

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

[Perlsau]

Zitat:

Zitat von Sunec (Beitrag 1312306)

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

Programmierlehrer schreiben in der Regel keine komplexen Programme (eine Ausnahme: Mathematiker) und verfügen meist nur über rudimentäre Programmierkenntnisse, die gerade dazu ausreichen, ihren Schülern die Grundkenntnisse zu vermitteln.

Zitat:

Zitat von Sunec (Beitrag 1312306)

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

Damit bist du gut beraten :thumb:

[bernau]

Zitat:

Zitat von Luckie (Beitrag 1312309)

Zitat:

Zitat von Sunec (Beitrag 1312306)

Also mein Programmierlehrer hatte damals immer zu with geraten

Die Begründung wäre jetzt interessant.

In vielen Büchern oder OnlineDokus wurde

Delphi-Quellcode:

with

angepriesen und die Vorteile aufgelistet. Leider hat man sich über die Nachteile keine Gedanken gemacht.

Vielleicht liest der Lehrer auch nicht hier im Forum mit.:lol:

Ich habe früher auch viel

Delphi-Quellcode:

with

verwendet. Allerdings schmeisse ich nun dies so nach und nach aus dem Quelltext heraus. Immer wenn ich auf einen Codeabschnitt mit with stoße.

[Luckie]

Zitat:

Zitat von bernau (Beitrag 1312320)

In vielen Büchern oder OnlineDokus wurde

Delphi-Quellcode:

with

angepriesen und die Vorteile aufgelistet.

Ok. Und welche wären das? Bitte jetzt nicht das Argument mit der Tipparbeit. Mit den heutigen IDEs und deren Codevervollständigung, sollte das nicht ins Gewicht fallen.

[Dejan Vu]

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

Zitat:

Zitat von Sir Rufo (Beitrag 1312310)

Haben wir immer so gemacht :mrgreen:

Zitat:

Zitat von Luckie (Beitrag 1312312)

Habe ich so ... gelernt. :mrgreen:

Zitat:

Zitat von Dejan Vu (Beitrag 1312317)

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

Andere gibt es nicht.

[bernau]

Zitat:

Zitat von Luckie (Beitrag 1312330)

Zitat:

Zitat von bernau (Beitrag 1312320)

In vielen Büchern oder OnlineDokus wurde

Delphi-Quellcode:

with

angepriesen und die Vorteile aufgelistet.

Ok. Und welche wären das? Bitte jetzt nicht das Argument mit der Tipparbeit. Mit den heutigen IDEs und deren Codevervollständigung, sollte das nicht ins Gewicht fallen.

Ich habe anscheinend die Vergangenheit nicht genug hervorgehoben.

Ich rede von eine Zeit, als Delphi 1 bis 5 noch aktuell war. Oder Glaubst du, daß die Lehrer ihr Wissen mit der aktuellen Delphi-Version erlangt haben?

[Sailor]

Schaut mal auf das Geburtsjahr von Pascal. Damals wurden Lochkarten als Eingabemedium benutzt. WITH hat da einiges gespart! Und dann die Resourcen, die ein Computer so hatte: Taktfrequenzen im einstelligen MHz-Bereich, Hauptspeicher von max 32.KB (PDP 11, eine herrliche Maschine). Mit optimierenden Compilern war noch nicht viel: Vom Ausdruck nach WITH wußte man, der kann gut in ein Register geladen werden, anstatt seinen Wert jedesmal neu zu berechnen. Ich benutze WITH heute noch da, wo das möglich ist, weil es den Code übersichtlicher macht. Es ist eben wie immer: Allein die Dosis macht das Gift.

[Luckie]

Zitat:

Zitat von Sailor (Beitrag 1312342)

Ich benutze WITH heute noch da, wo das möglich ist, weil es den Code übersichtlicher macht.

Und genau hie rgehen die Meinungen auseinander. Neben der potentiellen möglichen Fehler und der Inkonsitenz im Code, wenn man es mal so und mal so macht.

[Uwe Raabe]

Zitat:

Zitat von Bjoerk (Beitrag 1312278)

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:

Zitat von Dejan Vu (Beitrag 1312317)

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

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

Zitat:

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:

Zitat von Dejan Vu (Beitrag 1312334)

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

Zitat:

Zitat von Sir Rufo (Beitrag 1312310)

Haben wir immer so gemacht :mrgreen:

Zitat:

Zitat von Luckie (Beitrag 1312312)

Habe ich so ... gelernt. :mrgreen:

Zitat:

Zitat von Dejan Vu (Beitrag 1312317)

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

Andere gibt es nicht.

:stupid:

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.

[Mavarik]

Zitat:

Zitat von idefix2 (Beitrag 1312249)

With ist BÖSE

Ist doch quatsch...

With erspart Tiparbeit...

With einfach nur nicht für die letzte Ebene nehmen...

Beispiel:

Gegeben sei ein XML-Node: Balbla.blubblub.foofoo.barbar

Dann einfach

Delphi-Quellcode:

  With Balbla.blubblub do
    begin
      foofoo.barbar := 'Cool'
    end;

nehmen und nicht

Delphi-Quellcode:

  With Balbla.blubblub.foofoo do
    begin
      barbar := 'UnCool'
    end;

und schon ist alles prima...

[mkinzler]

Das wäre vielleicht die Lösung für den Fall den Uwe angesprochen hat (gemeint ist äusserer scope, der dann aber auf den inneren angewandt wird), aber sorgt dann dafür, dass es nun im umgekehrten Fall nicht funktioniert ( Entwickler erweitert den inneren scope, übersieht aber das die Eigenschaft übergeordnet schon existiert). Das Problem könnte man nur lösen, indem man die Möglichkeit schafft, den scope in den Eigenschaften zu spezifizieren ( wie in VB durch den Punkt asl Suffix).

[Sherlock]

Mavarik: With zerstört innerhalb seines Gültigkeitsbereichs die Fähigkeit des Debuggers Feldinhalte anzuzeigen. Darum gibt es bei mir kein with. Alles andere ist mir absolut egal. Das geschilderte Verhalten sticht alles aus, und macht damit with für mich zu einem NoGo.

Sherlock

[Sir Rufo]

Die Verwendung von

Delphi-Quellcode:

with

ist deswegen böse, weil es nur unter ganz speziellen Bedingungen halbwegs sicher ist (nur ein Scope -> nicht in einer Methode, ...).

Die Verwendung von

Delphi-Quellcode:

try ... except {nix} end;

ist deswegen böse, weil es nur unter ganz speziellen Bedingungen halbwegs sicher ist (in dem Codeblock kommen gar keine Exceptions, das Programm ist 100% fehlerfrei, ...).

Mit überhöhter Geschwindigkeit fahren ist auch böse, weil es auch nur unter ganz speziellen Bedingungen halbwegs sicher ist (abgesperrte Strecke, ...).

Das Risiko muss jeder für sich selber abschätzen. Wer kein Bock auf Risiko oder Random Application Developing hat - was macht meine Anwendung denn heute so - oder eben eine Anwendung die ohne erkennbaren Grund nicht mehr das macht, was sie machen soll, der verzichtet einfach auf die Verwendung von

Delphi-Quellcode:

with

,

Delphi-Quellcode:

try ... except {nix} end;

bzw. ballert nicht mit 120 durch eine Ortschaft.

Wenn es dann knallt, dann verbitte ich mir jedes wehleidige Gejammer "Das habe ich nicht gewollt!" - glaube ich sofort, aber billigend in Kauf genommen. Denn zu jedem Risiko gehört auch der richtige Hintern, den man dann in der Hose haben sollte, wenn es knallt. Erfahrungsgemäss ist das Verhältnis zwischen Risikobereitschaft und Hintern eher umgekehrt proportional ;)

[p80286]

Zitat:

Zitat von Sir Rufo (Beitrag 1312390)

Wenn es dann knallt, dann verbitte ich mir jedes wehleidige Gejammer "Das habe ich nicht gewollt!" - glaube ich sofort, aber billigend in Kauf genommen.;

Oder aus Unwissenheit gemacht, wenn so viele es machen kann's doch nicht falsch sein?

Zitat:

Zitat von Sir Rufo (Beitrag 1312390)

Denn zu jedem Risiko gehört auch der richtige Hintern, den man dann in der Hose haben sollte, wenn es knallt. Erfahrungsgemäss ist das Verhältnis zwischen Risikobereitschaft und Hintern eher umgekehrt proportional ;)

:thumb:

Gruß
K-H

[jaenicke]

Zitat:

Zitat von p80286 (Beitrag 1312399)

wenn so viele es machen kann's doch nicht falsch sein?

Das hat fast wortwörtlich eine ehemalige Nachbarin bezüglich ihres Rauchens gesagt. Und hinterher sinngemäß das:

Zitat:

Zitat von Sir Rufo (Beitrag 1312390)

wehleidige Gejammer "Das habe ich nicht gewollt!"

Sie ist vor 4,5 Jahren an Lungenkrebs gestorben.