Das with-Statement in XE4

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