Das with-Statement in XE4

[Codehunter]

Ich zitiere jetzt mal aus dem inzwischen geschlossenen Thread:

Zitat von Insider2004:

Ausserdem ist das with-Statement auch nicht mehr gerne gesehen.

Wie bitte? Was soll denn dann verwendet werden? Alles wieder lang ausschreiben? Na schönen Schrank auch! Wenn ich mir z.B. die TMS-Komponenten anschaue... Gigantische TPersistent-Kaskaden. Soll so die Zukunft aussehen:

Delphi-Quellcode:

FormComponent.Property1.SubProperty2.SubProperty3.BoolValue:= xyz;
FormComponent.Property1.SubProperty2.SubProperty3.IntValue:= 123;
FormComponent.Property1.SubProperty2.SubProperty3.StringValue:= 'xyz';

Statt so:

Delphi-Quellcode:

with FormComponent.Property1.SubProperty2.SubProperty3 do 
begin
  BoolValue:= xyz;
  IntValue:= 123;
  StringValue:= 'xyz';
end;

Oder

Delphi-Quellcode:

var
  fFForm: TForm;
begin
  fForm:= TForm.Create;
  try
    fForm.AnyThing:= Foo;
    fForm.OtherThing:= Bar;
  finally
   fForm.Free;
  end;
end;

Statt

Delphi-Quellcode:

with TForm.Create do try
  AnyThing:= Foo;
  OtherThing:= Bar;
finally
  Free;
end;

WTF?

[uligerhardt]

Ich sag mal: mit einer Variablen, wie in deinem zweiten Beispiel. Das erste finde ich, gelinde gesagt, sch*****.
Und wirklich überraschend kommt der Move ja auch nicht.

[Phoenix]

Nein, das erwartet keiner.
Das Problem mit with ist, dass es Scopes verschleiert.

Was ist, wenn Du in einem With-Block, den Wert von Tag des aktuellen Forms auf Sub-Controls schreiben willst? Bam-Scope-Konflikt.

Delphi-Quellcode:

with FormComponent.Property1.SubProperty2.SubProperty3 do 
begin
  BoolValue:= self.BoolValue;
  IntValue:= self.IntValue;
  StringValue:= self.StringValue;
end;

// wird dann zu
var myObject: TypeOfSubProperty3;

//...

myObject := FormComponent.Property1.SubProperty2.SubProperty3;
myObject.BoolValue:= BoolValue;
myObject.IntValue:= IntValue;
myObject.StringValue:= StringValue;

Letzlich sparst Du Dir damit sogar noch eine Zeile

[DeddyH]

Eben. Eine kleine Variable erspart die Tipparbeit, und übersichtlicher als with ist es auch noch.

Delphi-Quellcode:

var
  MyRecord: TSomeRecord;
begin
  MyRecord := SomeClass.SomeListClass[0].SomeSubClass.RecordProp;
  MyRecord.SomeInt := 42;
  MyRecord.SomeString := 'Wuppdi';

[edit] 2 L8 [/edit]

[Bernhard Geyer]

Zitat von DeddyH:

Eben. Eine kleine Variable erspart die Tipparbeit, und übersichtlicher als with ist es auch noch.

Und der Scope-Konflikt hat uns schon einige Tage Fehlersuche gekostet
Mittlerweile bauen wir es überall aus wenn wir eh was an der entsprechenden stelle ändern müssen.

[dataspider]

Und einen Ausdruck anzeigen im Debugger wird dann auch zur Freude...

Frank

[Uwe Raabe]

Zitat von Bernhard Geyer:

Und der Scope-Konflikt hat uns schon einige Tage Fehlersuche gekostet

Vor allen Dingen, wenn das durch Einführungen eines properties Width in TRect mal eben so mit einem Delphi-Update rein rutscht und Code, der vorher problemlos lief, plötzlich nur noch Müll produziert.

[Bernhard Geyer]

Zitat von Uwe Raabe:

Vor allen Dingen, wenn das durch Einführungen eines properties Width in TRect mal eben so mit einem Delphi-Update rein rutscht und Code, der vorher problemlos lief, plötzlich nur noch Müll produziert.

Genau. Hier liegt der Fehler an der Sprachdefinition. Hätte man es wie bei VB gemacht mit einem Punkt davor wäre alles klar gewesen.

[Mavarik]

Ohne with ist voll daneben...

Besonders beim Zugriff auf XML Dateien über ein Interface...

Aktuelles Beispiel
GrundDaten.Verfahrensdaten.Beteiligung.Beteiligter.Organisation.Registereintragung.Items[0].Inlaendisches_Registergericht.Registergericht_Ort.Content := 'Bonn'

Ohne With kann man das nicht mehr lesen oder mit arbeiten...
Und jedesmal ne Variable vom entsprechenden Untertypen definieren?

Schlechte wahl...

Mavarik

[jaenicke]

Zudem gibt es immer wieder Probleme, weil Code nicht mehr kompilierbar ist. Ein Beispiel ist die Einführung von zusätzlichen Features in TRect. Dort gibt es ja nun Offset, was aber leider in der VirtualStringTree genau innerhalb eines with benutzt wurde. Und schon war nur deswegen der Code nicht mehr kompilierbar.

Andere Punkte wurden ja schon genannt, wie der dass ein einfaches Debuggen so gut wie unmöglich wird, da man für jede einzelne Auswertung einer Variablen diese komplett in den Auswerten-Dialog schreiben bzw. kopieren muss (zusammen mit dem Anteil in with).

Das Zwei-Augen Prinzip beim Einchecken wird auch zur Farce, weil dabei niemand den Überblick wahren kann, wenn überall with steht. Da bleibt daher immer ein Unsicherheitsfaktor.
Welche Eigenschaften wo existieren, kann niemand immer auswendig wissen, zumal sich dies auch durch neue Features in der RTL ändert.

Davon abgesehen macht with in meinen Augen auch keinen Sinn. Der einzige "Vorteil" ist, dass man vielleicht etwas weniger tippen muss. Aber als Entwickler darf man ja nun wirklich nicht tippfaul sein, viel tippen gehört schließlich dazu...
Der riesige Zeit- und damit Kostenaufwand, der dann aber folgt, weil der Code schlechter zu warten ist, ist damit jedenfalls gar nicht vergleichbar. Ein Musterbeispiel für eine Milchmädchenrechnung.

Zitat von Bernhard Geyer:

Mittlerweile bauen wir es überall aus wenn wir eh was an der entsprechenden stelle ändern müssen.

Wir auch...

Ich selbst habe es auch nie wirklich viel benutzt. Gut, am Anfang als ich noch nicht beruflich entwickelt habe, da habe ich über die Folgen nicht so sehr nachgedacht und es kam schon mal in meinen Quelltexten vor, aber nur selten.

Zitat von Mavarik:

Und jedesmal ne Variable vom entsprechenden Untertypen definieren?

Das ist allemal besser als with.