Proleme bei Locate

[himitsu]

Ich bezog meine Aussage ausschließlich auf diesen Code und da ist es nutzlos und verbessert das Codeverständnis auch nicht wirklich.

(with ... do anstatt einem . )

Und wie du schon sagtest, ist es eher hinderlich.

- keine Vorteile
- unnötiger Code, welcher den Lesefluß eher behindert
- beim Debuggen oftmals hinderlich
= Vorteile 0 und Nachteile (mindestens) 3

[mkinzler]

Das Problem mit with ist, dass es zu sehr komplexen schlecht identifizierbaren Fehlern führen kann, wenn die Eigenschaft/Methode des falschen Objektes aufgerufen wird. Das kann passieren wenn bei einem Update der VCL Klassen neue Eigenschaften/Methoden bekommen. Dies ist bei XE2 passiert und hat bei Einigen zu massiven Problemen geführt.

[Furtbichler]

Ja das wissen wir ja alles.

Zitat von mkinzler:

..Dies ist bei XE2 passiert und hat bei Einigen zu massiven Problemen geführt.

Das ist *NICHTS* im Vergleich zum Wechsel des Datentyps 'String' von Ansi auf Wide. Und ist 'String' deshalb nutzlos, böse und falsch?

Wenn es jemand verwenden will, so wie ich z.B. seit 30 Jahren, und damit keine Probleme hat, erfolgreiche Projekte durchgezogen hat und die Haare immer noch gleichmäßig wachsen und es auch sonst mit der Verdauung, dem Privatleben, den Freunden, dem Beruf und überhaupt klappt, wieso ist das dann so schlecht?

Es erleichtert das Lesen des Codes, wenn man es sinnvoll einsetzt(!).

Ich kann mir nämlich Endloszeilen sparen.
[DELPIH]
MyLongObjectName.TheComplicatedProperty.AndThisIsC omplex.Value := MyLongObjectName.TheComplicatedProperty.AndThisIsC omplex.Strings.IndexOf(MyLongObjectName.TheComplic atedProperty.AndThisIsComplex.Text);
[/DELPHI]
Hat was. Künstlerisches. Irgendwie.
[DELPIH]
With MyLongObjectName.TheComplicatedProperty.AndThisIsC omplex Do
Value := Strings.IndexOf(Text);
[/DELPHI]
Finde ich viel einfacher zu verstehen und funktioniert, da Tippfehler fast ausgeschlossen sind. Beim Lesen spare ich Zeit. Ich muss natürlich wissen, das 'Strings' und 'Text' zu 'AndThisIsComplex' gehören, aber ich lese Code ja nicht, um zu lernen, sondern um ihn zu verstehen.

Klar, ein WITH über drei Seiten ist etwas dümmlich, aber das sind Methodenrümpfe auch (die zu lang sind).

Es gibt immer Möglichkeiten, etwas Sinnvolles so anzuwenden, das es krank wird. Das ist mit 'WITH' so, aber auch mit GOTO, EXIT, BREAK, CONTINUE, WHILE, REPEAT usw. Also mit so ziemlich jedem Sprachkonstrukt.

Ich schlage mich allerdings nicht darum, es benutzen zu dürfen, denn es geht auch ohne (z.B. mit einer Aliasvariablen)

Delphi-Quellcode:

a := MyLongObjectName.TheComplicatedProperty.AndThisIsComplex;
a.Value := a.Strings.IndexOf(a.Text);

Ach, und das mir keiner kommt und sagt:"Büschen viel Wind um Nichts".

[mkinzler]

Zitat:

Das ist *NICHTS* im Vergleich zum Wechsel des Datentyps 'String' von Ansi auf Wide. Und ist 'String' deshalb nutzlos, böse und falsch?

Damit hatte man aber nur Probleme, wenn man sich auf inoffizielle Implementierungsdetails verlassen hat. Beim "sauberen" Umgang mit Strings gab es keine Probleme.
Bei with besteht nun mal die Gefahr, das es zu Scope-Verschiebungen kommt und deshalb würde ich darauf verzichten.
Auf "offizieller" Seite sieht man das ja auch ähnlich.

http://stackoverflow.com/questions/5...a-bad-practice

[Flash68]

Kann man dann auch sowas umarbeiten ohne with?

Delphi-Quellcode:

procedure TFRM_Main.DBG_BuecherTitleClick(Column: TColumn);
begin
  with DM_Buecher.ADS_Buecher do
    if sort = Column.Field.FieldName then
      sort := Column.Field.FieldName + ' DESC'
    else
      sort := Column.Field.FieldName
end;

[mkinzler]

Delphi-Quellcode:

procedure TFRM_Main.DBG_BuecherTitleClick(Column: TColumn);
begin
    if sort = DM_Buecher.ADS_Buecher.Column.Field.FieldName then
      sort := DM_Buecher.ADS_BuecherColumn.Field.FieldName + ' DESC'
    else
      sort := DM_Buecher.ADS_BuecherColumn.Field.FieldName
end;

oder

Delphi-Quellcode:

procedure TFRM_Main.DBG_BuecherTitleClick(Column: TColumn);
var
  fieldname: string;
begin
    fieldname := DM_Buecher.ADS_Buecher.Column.Field.FieldName:
    if sort = fieldname then
      sort := fieldname + ' DESC'
    else
      sort := fieldname;
end;

[Flash68]

die funktionieren beide nicht so recht:

bei der ersten Variante kennt er das sort nicht und kann nichts mit

DM_Buecher.ADS_Buecher.Column.Field.FieldName anfangen

bei der zweiten kann er nichts mit

Column.Field.FieldName: anfangen

[mkinzler]

Zu welcher Klasse gehören die beiden Eigenschaften?

[himitsu]

Delphi-Quellcode:

  with DM_Buecher.ADS_Buecher do
    if sort = Column.Field.FieldName then
      sort := Column.Field.FieldName + ' DESC'
    else
      sort := Column.Field.FieldName

Wenn alles* unterhalb des WITH zu der Klasse gehört, welche direkt im WITH gekapselt wurde, dann gibt es meistens keinerlei Probleme,
aber wie man bei Umstellungen auf XE2, oder sonstigen Umstellungen oder Erweiterungen von Klassenstrukturen, gesehn hat, gibt es sofort Probleme, wenn sich z.B. Methoden/Property im Scope verschieben, bzw. wenn sich plötzlich Gleichnamiges dazwischenschiebt (im Scope auftaucht).

*) Property, Methoden/Funktionen, Felder und (eingebettete) Typen und Konstanten


WITH kann ein mächtiges Werkzeug sein, womit man sich Arbeit erspart,
aber man sollte es nicht inflationär und mit vorallem mit Bedacht einsetzen.

Und in dem hier vorliegendem Fall war es nunmal vollkommen nutzlos und brachte keinerlei Vorteile.

Zitat:

with ... do anstatt einem .

[Sir Rufo]

Zitat von mkinzler:

Zu welcher Klasse gehören die beiden Eigenschaften?

Das sieht man doch

Column ist ein Parameter der Methode und Sort ist eine Property von DM_Buecher.ADS_Buecher