Das with-Statement in XE4

[DeddyH]

Das kam ja von mir, da hatte ich wohl etwas verwechselt. Aber da ich persönlich with meide wie der Teufel das Weihwasser und außerdem keine XE4-Lizenz besitze, konnte ich die Behauptung auch nicht verifizieren. Man möge mir vergeben

[mkinzler]

Man hat überlegt das with-Statement beim nextgen-compiler (ARM) zu entfernen; es ist aber doch drin. Wie aber diverse Probleme durch Erweiterungen der Klassenbibliothek zeigen, sollte man es in seinem Quellcode ersetzen.

[Codehunter]

Also ich habe eine XE4-Lizenz und kann mit Sicherheit bestätigen dass with dort noch unterstützt wird.

Ich kann mir auch beim besten Willen nicht vorstellen, dass das wirklich irgendwann komplett raus fliegt. Wenn ich mir anschaue, wie viele Sourcen noch exzessiven Gebrauch davon machen glaube ich dass ein Verzicht auf with seitens Emba ein größeres Erdbeben wäre als die Umstellung von Ansi- auf Unicodestrings.

Und - jetzt dürft ihr mich gerne steinigen - ich liebe with, kann auch die häufig geäußerte Kritik daran nicht nachvollziehen. Zumindest nicht in flachen with-Strukturen. Ich verwende es nicht verschachtelt und habe (ohne Flachs!) noch nie Zuordnungsfehler gehabt.

Jetzt müsst ihr mich aber nicht überzeugen, warum wieso weshalb with nun sooooo böse ist. Ich und Emba sind allzu oft unterschiedlicher Meinung, die sitzen am längeren Hebel, hab mich dran gewöhnt. Wenn sie mich irgendwann zu viel geärgert haben such ich mir eben ne andere IDE und mein Geld fließt dann woanders hin. Dann sitz ich am längeren Hebel. Doll, wa?

[mkinzler]

Wenn Du bisher keine Probleme hattest, dann freu Dich. Diejenigen die wegen eines Scopeproblems in einem with-Statement stundenlang Fehler gesucht haben "lieben" es halt nicht mehr. EM hat es nach Widerstand ja entschlossen es nicht zu entfernen.
With auf eigene Strukturen ist ja ok, aber wenn man es auf fremde Klassenhierarchien ansetzt, muss man sich halt bewusst sein, dass Erweiterungen an denen den Code brechen kann.

[musicman56]

Zitat von Codehunter:

Und - jetzt dürft ihr mich gerne steinigen - ich liebe with, kann auch die häufig geäußerte Kritik daran nicht nachvollziehen. Zumindest nicht in flachen with-Strukturen. Ich verwende es nicht verschachtelt und habe (ohne Flachs!) noch nie Zuordnungsfehler gehabt.

+1 Das Stichwort ist denke ich "Zumindest nicht in flachen with-Strukturen."

[DeddyH]

Es kommt ja wahrlich nicht allzu häufig vor, dass ich BASIC lobe, aber dort ist das eindeutig besser gelöst. Hätte man das bei Pascal von Anfang an genauso gemacht, hätte ich absolut keine Einwände gegen den Gebrauch von with.

[Codehunter]

Ich denke, das Problem liegt eigentlich woanders. With sollte ja ursprünglich die Lesbarkeit des Codes verbessern. Während Klassennamen innerhalb der VCL noch sehr prägnant sind, neigen die Programmierer oft zu "sprechenden" Variablennamen, also halben Sätzen (nur eben ohne Leerzeichen). In der Konsequenz hat man ohne with zu benutzen einen sehr vollgemüllten Code.

Ein Beispiel:

Delphi-Quellcode:

initialization

type
  TMyRec = record
    SomeState: Boolean;
    OtherState: Boolean;
  end;

var
  SomeStateOfASpecificControlWhenUserHasChecked: TMyRec;

implementation

procedure Form.Foo;
begin
  btnSave.Enabled:= SomeStateOfASpecificControlWhenUserHasChecked.SomeState;
  if not SomeStateOfASpecificControlWhenUserHasChecked.SomeState then 
    btnSave.OnClick:= NIL
  else
    btnSave.OnClick:= btnSaveClick;
end;

Jetzt kann man das entweder in eine "kurze" lokale Variable ummünzen:

Delphi-Quellcode:

initialization

type
  TMyRec = record
    SomeState: Boolean;
    OtherState: Boolean;
  end;

var
  SomeStateOfASpecificControlWhenUserHasChecked: TMyRec;

implementation

procedure Form.Foo;
var
  SomeState: Boolean;
begin
  SomeState:= SomeStateOfASpecificControlWhenUserHasChecked.SomeState;
  btnSave.Enabled:= SomeState;
  if not SomeState then 
    btnSave.OnClick:= NIL
  else
    btnSave.OnClick:= btnSaveClick;
end;

oder man benutzt with:

Delphi-Quellcode:

initialization

type
  TMyRec = record
    SomeState: Boolean;
    OtherState: Boolean;
  end;

var
  SomeStateOfASpecificControlWhenUserHasChecked: TMyRec;

implementation

procedure Form.Foo;
begin
  with SomeStateOfASpecificControlWhenUserHasChecked do begin
    btnSave.Enabled:= SomeState;
    if not SomeState then 
      btnSave.OnClick:= NIL
    else
      btnSave.OnClick:= btnSaveClick;
  end;
end;

Ok, war jetzt nur Pseudocode aber ich denke man kanns interpretieren. Die kürzeste und lesbarste Version ist für mich die letztere. Zumal die Verwendung einer lokalen Variable ein weiteres Problem aufwirft: Handelt es sich dann im konkreten Fall um einen Zeiger auf das eigentliche Objekt/Variable oder um eine Kopie des Objektes/Variable? Das ist sicherlich auch nicht in allen Fällen eindeutig. Gerade bei Zuweisungen an globale Records (nicht Klassen) hab ich da schon Schwierigkeiten gehabt.

Wenn jemand mal in ein Scope-Problem verwickelt war, kann ich gut verstehen dass man dann gefrustet ist. Aber es gibt andere Arten von Problemen, die einem nicht weniger Zeit kosten. Wilde Pointer-Schubsereien zum Beispiel. Sollte man deshalb den Pointer-Typ auch gleich aus der Sprache entfernen?

Ich würde es dagegen sehr begrüßen, wenn man den Compiler ein bisschen aufbohren würde um ihn vor mehrdeutigen Scopes warnen zu lassen - vergleichbar mit den Warnungen bei mehrdeutigen Aufrufen überladener Funktionen. Damit hab ich grad bei einem Ansi-Unicode-Port meinen Spaß...

[jaenicke]

Zitat von musicman56:

+1 Das Stichwort ist denke ich "Zumindest nicht in flachen with-Strukturen."

Auch da gab es schon öfter Probleme in letzter Zeit...
Es sind eben auch in vordefinierten Datentypen wie TRect Funktionen wie Offset hinzugekommen. Selbst wenn das dann (wie bei der TVirtualStringTree) nur zwei Zeilen im with sind, es hat dann bei XE2 geknallt.

Zitat von Codehunter:

Ok, war jetzt nur Pseudocode aber ich denke man kanns interpretieren. Die kürzeste und lesbarste Version ist für mich die letztere.

Kürzeste ja, lesbarste finde ich absolut nicht. Denn man setzt damit beim Leser des Codes voraus, dass er immer genau weiß welche Eigenschaften das andere Objekt hat und welche nicht. Und man setzt voraus, dass sich das auch in dem anderen Objekt nie ändert, da sonst neu eingeführte Eigenschaften solche der Elternklasse beim Aufruf verdecken können.
Wenn die dann noch den selben Typ haben, kann der Compiler das auch nicht feststellen.

Und das ist genau das gegenteil von guter Lesbarkeit. Denn zu guter Lesbarkeit gehört, dass man immer eindeutig sieht was wozu gehört. Und das ist mit with definitiv nicht der Fall.

[Codehunter]

Lach das ist wie die Diskussion Startmenü vs. Kacheldingsbums: Man tauscht Argumente aus und kommt doch nie zu einem Ergebnis.

Das Argument mit Änderungen an Basisklassen zieht meiner Ansicht nach nicht. Denn Änderungen an Basisklassen können zu vielfältigen Problemen führen. Nicht nur mit with.

Ich sage doch gar nicht, dass with nicht problematisch ist. Ich sage nur, es ist Sache der Programmierer (also uns!) lesbaren Code zu produzieren. Das Thema Codeformatierung bewegte sich schon immer irgendwo zwischen technischer Notwendigkeit, Sachlichkeit, Ästhetik und Philosophie. Bekanntermaßen gibt es bei letzteren beiden keine eindeutige Linie.

Wichtig ist nur, dass es keine gute Idee wäre, with aus dem Compiler zu werfen. Man wäre sicher überrascht, an wie vielen Stellen das verwendet wird ohne dass man da je reingeschaut hat (und verwendet es trotzdem). Compilerwarnungen, OK. Support über Direktiven ein- und ausschaltbar, OK. Aber komplett ersatzlos streichen, NO WAY.

[jaenicke]

Zitat von Codehunter:

Das Thema Codeformatierung bewegte sich schon immer irgendwo zwischen technischer Notwendigkeit, Sachlichkeit, Ästhetik und Philosophie. Bekanntermaßen gibt es bei letzteren beiden keine eindeutige Linie.

With und Codeformatierung zu vergleichen ist wie Äpfel mit Raumschiffen. With blendet einen zusätzlichen Scope über den Bereich, den es abdeckt. Und da kann man formatieren wie man will, man sieht trotzdem nicht was woher kommt.

Einen schlecht formatierten Quelltext hingegen kann man einfach durch einen Codeformatter jagen und kann das so beheben. Das geht bei with nicht.

Zitat von Codehunter:

Wichtig ist nur, dass es keine gute Idee wäre, with aus dem Compiler zu werfen.

Ich bin auch nur für eine Compilerwarnung.

Ganz einfach auch deshalb, weil es extrem aufwendig ist innerhalb von with für jeden einzelnen Bezeichner festzustellen wozu der gehört um das with aufzulösen. Genauso wie eine Änderung eines Quelltextes mit with darin sehr aufwendig ist.
Das hat bei uns schon einige Manntage gekostet und bei uns ist der Quelltext bei weitem nicht so groß wie bei manchen größeren Firmen... und bei uns steckt noch an vielen Stellen with drin, genau aus dem Grund.

Bevor ich allerdings alten Code mit with debugge, korrigiere ich das lieber und debugge dann bequem ohne with weiter.