Das with-Statement in XE4

[jensw_2000]

Zitat:

Zitat von Phoenix (Beitrag 1212360)

Äh.. wir entfernen und gerade mit Warp 4 von den With-Statements...

Sorry.

Das es Vieles gibt, dass gehen die Verwendung von with spricht und dass es dennoch praktisch sein kann es zu verwenden dütfte klar geworden sein.

Ich denke jedoch, EMBT das whith in zukünftigen Kompilerversionen nicht eliminieren darf. Wenn with wirklich "sooo böse" ist, dann soll es von mir aus eine Option a'la Oxygens "allow legacy 'with'" gehen die standardmäßig deaktiviert ist.
Dann eventuell noch ein Kompiler-Hinweis, falls er auf einen With-Block trifft.

War garnicht gehen würde ist, With einfach "abzuschalten" und den Entwicklern unzähliche unproduktive Stunden für die Umstellung deren Quellcodes aufzuhalsen.

Das der Debugger Probleme in With Blöcken hat ist wirklich nicht schön. Dies sehe ich aber nicht als Problem des With Statenments sondern als Schwäche des Debuggers. Letztendlich weis der, in welchen Scope er sich gerade befindet.

[Bernhard Geyer]

Zitat:

Zitat von jensw_2000 (Beitrag 1212367)

Ich denke jedoch, EMBT das whith in zukünftigen Kompilerversionen nicht eliminieren darf. Wenn with wirklich "sooo böse" ist, dann soll es von mir aus eine Option a'la Oxygens "allow legacy 'with'" gehen die standardmäßig deaktiviert ist.
Dann eventuell noch ein Kompiler-Hinweis, falls er auf einen With-Block trifft.

Irgendwann darf es schon eliminiert werden. Muss halt ein paar Jahre dauern.

1. Nachfolgeversion: Compilerschalter mit "with als warnung"
2. Nachfolgeversion: Compilerschalter entfernt, with immer Warnung
3. Nachfolgerversion: with ergibt immer Fehler

[hanspeter]

Warum with nicht an die Form wie in Prism/Oxygene anpassen.
Pascal ist doch schon lange (gefühlt 100 Jahre) keine Lehrsprache mehr, sondern soll der produktiven Programmierung dienen.
Delphi-Pascal ist, von wenigen Ausnahmen abgesehen, syntaktisch auf den Stand von 1990.
Ein paar modernere Konstrukte in der Syntax von Delphi sollten wohl möglich sein.


peter

[jensw_2000]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1212368)

Irgendwann darf es schon eliminiert werden. Muss halt ein paar Jahre dauern.

1. Nachfolgeversion: Compilerschalter mit "with als warnung"
2. Nachfolgeversion: Compilerschalter entfernt, with immer Warnung
3. Nachfolgerversion: with ergibt immer Fehler

Das geht zu schnell.
Wir sind mit XE4 bei einem halbjährigen Releasewechsel angekommen und nicht jeder benutzt immer die neueste Version.
Falls man plant ein Sprachfeature zu entfernen, dass es seit Jahrzehnten gab, dann sollte man es auch mindestens 5-10 Jahre abkündigen bevor man es entfernt. Wo wäre denn sonst die Investitionssicherheit?

[jaenicke]

Zitat:

Zitat von hanspeter (Beitrag 1212370)

Delphi-Pascal ist, von wenigen Ausnahmen abgesehen, syntaktisch auf den Stand von 1990.
Ein paar modernere Konstrukte in der Syntax von Delphi sollten wohl möglich sein.

So wenige Neuerungen sind das auch syntaktisch zwar nicht, aber das sehe ich prinzipiell auch so.

[Insider2004]

Zitat:

Zitat von jaenicke (Beitrag 1212378)

Zitat:

Zitat von hanspeter (Beitrag 1212370)

Delphi-Pascal ist, von wenigen Ausnahmen abgesehen, syntaktisch auf den Stand von 1990.
Ein paar modernere Konstrukte in der Syntax von Delphi sollten wohl möglich sein.

So wenige Neuerungen sind das auch syntaktisch zwar nicht, aber das sehe ich prinzipiell auch so.

1990? Völliger Quatsch. Was soll das bitte sein? Meine Wünsche, die ich schon vor 10 Jahren hatte, nach Unicode, Generics und ARC (teilweise) wurden jetzt erfüllt. Wenn der Win32 compiler dann auch volle ARC Unterstützung hat, wird hochgerüstet.

[Bernhard Geyer]

Zitat:

Zitat von hanspeter (Beitrag 1212370)

Delphi-Pascal ist, von wenigen Ausnahmen abgesehen, syntaktisch auf den Stand von 1990.
Ein paar modernere Konstrukte in der Syntax von Delphi sollten wohl möglich sein.

Stand 1990? Da gabs nicht mal Delphi 1!
Es ist schon viel gemacht (Generics, Unicode, Erweiterte RTTI, ...)

[Furtbichler]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1212425)

Zitat:

Zitat von hanspeter (Beitrag 1212370)

Delphi-Pascal ist, von wenigen Ausnahmen abgesehen, syntaktisch auf den Stand von 1990. ...

Stand 1990? Da gabs nicht mal Delphi 1!...

Aber *Pascal*. Ich vermute ganz stark, das hanspeter dies mit dem Zusatz 'Delphi-Pascal ausdrücken wollte.

Java kam ein paar Jahre später auf den Markt und ist heute Quasistandard. Ähnlich C++ (obwohl ich das nicht mag). Die Sprachen haben logischerweise eine Entwicklung durchgemacht, nur Delphi-Pascal eben nicht.

Und dieses 'with' ist nun wirklich der unwichtigste Bestandteil der Sprache, den es zu verändern gibt. Wo es sinnvoll ist, z.B. bei der Initialisierung von Records/Klassen, gibt es in anderen Sprachen (z.B. C# und dem 'Initializer' bei der Instantiierung) ähnliche Ansätze.
[OT]
Und bezüglich der 0-Strings kann ich nur sagen, das damit Delphi für mich entgültig gestorben ist. Nicht, weil ich nicht mit 0-Strings klar komme, sondern weil die Leute, die das entscheiden, offensichtlich gegen ihre Gehirnwindungen gebürstet sind, sollte ein 'String' wirklich plötzlich seine Basis von 1 auf 0 ändern. Ich setze nicht auf ein Produkt, deren Manager und Entscheider weltfremd sind. Tut mir leid.
[/OT]

Edit: Der letzte Absatz gehört nicht hierhin

[Insider2004]

Man könnte auch sagen, Pascal wurde von Niklaus Wirth fast perfekt mit ruhiger Hand designed. Da brauchte es nicht mehr viel Durchmachentwicklung. Bei Java und C sieht man ganz deutlich das hektische Design. Die Usability war schon immer eine Katastrophe. Warum das bei den Leuten so beliebt ist, bleibt mir ein Rätsel. Muss in der menschlichen Natur liegen, dass man sich gern ins Chaos stürzt. Jedenfalls habe ich den Eindruck nach 30 Jahren Pascal, dass sich Pascaler lieber um die Probleme kümmern und die Javeianer/Cler um die Sprache selbst (wobei die doppelte Leistung für den gleichen Output erbringen müssen).

[jensw_2000]

Zitat:

Zitat von Insider2004 (Beitrag 1212445)

Bei Java und C sieht man ganz deutlich das hektische Design. Die Usability war schon immer eine Katastrophe.

Auf diesem Pfad befinden wir uns doch auch seit XE2 und FireMonkey. Zuerst wurde die RTL verbogen um VCL und FMX unter einen Hut zu bekommen. Jetzt verbiegt man Hals über Kopf die grundgelenden Sprachelemente, um eine Cross-Plaform Unterstützung zu schaffen die nie wirklich "nativ" auf den Plattformen laufen kann, weil sie "nur" auf OpenGL basiert und nicht auf den APIs der jeweiligen Plattform.

[hanspeter]

Zitat:

Zitat von Insider2004 (Beitrag 1212445)

Man könnte auch sagen, Pascal wurde von Niklaus Wirth fast perfekt mit ruhiger Hand designed. Da brauchte es nicht mehr viel Durchmachentwicklung.

Deshalb hat er dann auch die Nachfolger von Pascal, Modula (1973–1976), Modula-2 (1977–1980) und Oberon (1985–1990) entwickelt.

Zitat:

Zitat von Insider2004 (Beitrag 1212445)

1990? Völliger Quatsch. Was soll das bitte sein? Meine Wünsche, die ich schon vor 10 Jahren hatte, nach Unicode, Generics und ARC (teilweise) wurden jetzt erfüllt.

Du sagst es 10 Jahre..

Im übrigen habe ich den Eindruck, dass Du Delphi und Religion verwechselst.

Peter

[jfheins]

Zitat:

Zitat von Insider2004 (Beitrag 1212445)

Man könnte auch sagen, Pascal wurde von Niklaus Wirth fast perfekt mit ruhiger Hand designed. Da brauchte es nicht mehr viel Durchmachentwicklung.

LOL :lol:
Also z.B. gibt es hier so ein tolles Paper: http://www.cs.utexas.edu/users/EWD/t...xx/EWD831.html
Der nette Herr hat da ein valides Argument für 0-basierte Indices. Und jetzt schau mal auf Pascal: Der Index in Array fängt bei 0 an, in Strings bei 1. Und das soll "fast perfekt mit ruhiger Hand designed" sein?

Zitat:

Bei Java und C sieht man ganz deutlich das hektische Design. Die Usability war schon immer eine Katastrophe. Warum das bei den Leuten so beliebt ist, bleibt mir ein Rätsel. Muss in der menschlichen Natur liegen, dass man sich gern ins Chaos stürzt. Jedenfalls habe ich den Eindruck nach 30 Jahren Pascal, dass sich Pascaler lieber um die Probleme kümmern und die Javeianer/Cler um die Sprache selbst (wobei die doppelte Leistung für den gleichen Output erbringen müssen).

Beschäftige dich mal ein wenig mit C# oder Prism. Ein wunderbares Sprachdesign, da vieles von Anfang an berücksichtigt wurde. Und was genau meinst du wenn du von "hektischem Design" und fehlender Usability schreibst? Dass man Variablen überall deklarieren kann? Geschweifte Klammern?

P.S.: Bei der Entwicklung von C# hat der Wirth einiges dazu getan, falls man also annimmt dass er weiser geworden ist (und nicht senil), dann wäre eher C# die "fast perfekt designete" Sprache - da konnte er dann auch aus den Fehlern in Delphi lernen :mrgreen:

Du siehst schon, ich kann da leider nur raten, was genau du meinst :glaskugel:

[gammatester]

Zitat:

Zitat von jfheins (Beitrag 1212472)

Und jetzt schau mal auf Pascal: Der Index in Array fängt bei 0 an, in Strings bei 1. Und das soll "fast perfekt mit ruhiger Hand designed" sein?

Die Strings kommen allerdings von Borland nicht von Wirth! Und wie wir alle wissen, sind in Pascal (fast) beliebige Arraygrenzen möglich.

[Daniel]

In XE5 wird uns das With-Statement in allen Compilern erhalten bleiben.

[Union]

Zitat:

Zitat von gammatester (Beitrag 1212481)

Zitat:

Zitat von jfheins (Beitrag 1212472)

Und jetzt schau mal auf Pascal: Der Index in Array fängt bei 0 an, in Strings bei 1. Und das soll "fast perfekt mit ruhiger Hand designed" sein?

Die Strings kommen allerdings von Borland nicht von Wirth! Und wie wir alle wissen, sind in Pascal (fast) beliebige Arraygrenzen möglich.

Naja, Abwärtskompatibilität halt, da bei den ShortStrings an der ersten Stelle die Länge steht.

Zitat:

Zitat von Daniel

In XE5 wird uns das With-Statement in allen Compilern erhalten bleiben.

Psssst!

[mkinzler]

Man muss aber mit Alternativen nicht warten, bis etwas endgültig weg ist!

[Der schöne Günther]

Ich kann nicht mit Weisheit durch lange Delphi-Erfahrung punkten, aber anfangs fand ich

Delphi-Quellcode:

with

auch toll und habe es ein paar mal verwendet. Nach ein paar Wochen war ich auf Fehlersuche und brauchte eine ganz schöne Weile, um - was sonst - einen bösen with-Block zu finden der verantwortlich war.

With wird mit Sicherheit nicht gewaltsam aus der Sprache gerissen werden, aber für eine (einstellbare) Compiler-Warnung wird es wirklich langsam Zeit. Für Strings und Indizes gibt es das ja auch schon.

[DeddyH]

Wir können ja eine Gruppe gründen: "With ist doof" :mrgreen:

[Daniel]

Zitat:

Zitat von DeddyH (Beitrag 1227325)

Wir können ja eine Gruppe gründen: "With ist doof" :mrgreen:

Ist mir allemal lieber als diese ständigen Gruppen "der Admin ist doof". :stupid:
:mrgreen:

[DeddyH]

Da bin ich Ehrenmitglied :duck: :lol:

[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 :angel2:

[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? :-D

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

Zitat von Codehunter (Beitrag 1227378)

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." :thumb:

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

Zitat von musicman56 (Beitrag 1227382)

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

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:

Zitat von Codehunter (Beitrag 1227387)

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:

Zitat von Codehunter (Beitrag 1227395)

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:

Zitat von Codehunter (Beitrag 1227395)

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.

[Codehunter]

Zitat:

Zitat von jaenicke (Beitrag 1227399)

With und Codeformatierung zu vergleichen ist wie Äpfel mit Raumschiffen.

Na sag das mal der Firma Apple mit ihren außerirdisch teuren Geräten ;-)

Zitat:

Zitat von jaenicke (Beitrag 1227399)

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.

Menno jetzt haste mich dazu gebracht, darüber nachzudenken wie ich das normalerweise handhabe, genau dieses rauszufinden. Dabei bin ich zu dem Ergebnis gekommen, dass ich aus mir selbst nicht ganz ersichtlichen Gründen gewohnheitsmäßig with nur dort anwende, wo es keine mehrdeutigen Scopes gibt. In anderen Fällen verwende ich dagegen eher Assign() oder schreibe eine Assign-Methode.

Zitat:

Zitat von jaenicke (Beitrag 1227399)

Einen schlecht formatierten Quelltext hingegen kann man einfach durch einen Codeformatter jagen

Ich hasse nichts mehr als maschinenformatierten Code. Da fehlt einem doch die persönliche Note :-D

Zitat:

Zitat von jaenicke (Beitrag 1227399)

Ich bin auch nur für eine Compilerwarnung.

Na dann ist die Welt doch wieder schön ;-)

Zitat:

Zitat von jaenicke (Beitrag 1227399)

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

Vorallem bezahlt niemand solche internen Umstellungen bzw. man bezahlt das Unterlassen der selben später durch erhöhten Wartungsaufwand (das stell ich ja gar nicht in Abrede)

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1227410)

Ich hasse nichts mehr als maschinenformatierten Code. Da fehlt einem doch die persönliche Note :-D

Ich schreibe Quelltext automatisch fast 1:1 so wie der integrierte Formatter den formatiert, benutze den also auch nicht. ;-)
Ich finde das so (abgesehen von Einrückungen bei anonymen Methoden und nested var Sektionen...) übersichtlich. Aber an der Stelle ist das auch eher Geschmackssache, deshalb habe ich da absolut kein Problem, wenn es jemand anders macht... sofern es sinnvoll und einheitlich ist.

[Codehunter]

Mich persönlich stören vorallem die Zeilenumbrüche vor einen begin, wie es die Formatter tun:

Delphi-Quellcode:

procedure Foo;
begin
  while bSomeBool do
  begin
    Bar(Param);
  end;
end;

Schlimmer noch die doppelte Einrückung:

Delphi-Quellcode:

procedure Foo;
begin
  while bSomeBool do
    begin
      Bar(Param);
    end;
end;

Ich bevorzuge es lieber so:

Delphi-Quellcode:

procedure Foo;
begin
  while bSomeBool do begin
    Bar(Param);
  end;
end;

So und jetzt möchte ich fast meinen Hintern darauf verwetten dass gleich die nächste Diskussion los geht warum ein begin seine eigene Codezeile haben muss ^^

[Daniel]

Nein, das wird nicht passieren.
Bleibt bitte beim Thema "with" oder lasst es für den Moment einfach gut sein.

[Codehunter]

Ich möcht echt kein Admin hier sein bei den ganzen notorischen Offtopicern wie mir ^^ Insofern :thumb:

Um auf das Eingangsthema zurückzukommen, mkinzler hat meine Ursprungsfrage inzwischen erschöpfend beantwortet:

Zitat:

Zitat von mkinzler (Beitrag 1227381)

EM hat es nach Widerstand ja entschlossen es nicht zu entfernen.

[p80286]

Zitat:

Zitat von jaenicke (Beitrag 1227399)

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.

Nachdem ich auch schon mal Stunden beim debuggen verbracht habe, ist "with" aus meinem Wortschatz gestrichen.
[OT]
genauso wie die beliebten Zweibuchstabenaliasse in SQL [/OT]

Gruß
K-H

[Furtbichler]

Ich verwende 'with', wenn es mir in den Kram passt, nicht nervt und mich nicht konfus macht. Es gibt Strukturen, die sind enorm komplex und da ist ein 'with' hilfreich und fördert die Übersichtlichkeit.

Blöd wird es beim Debuggen, aber solange das, was ich da schreibe, unwichtig ist, soll es mir doch recht sein.

Daraus eine Religion zu machen, ist nun wahrlich Kleinkindgehabe, ebenso wie irgendwelche Diskussionen über Handformatierung: Laiengeschwätz in meinen Augen.

Zitat:

Zitat von jaenicke (Beitrag 1227399)

Ganz einfach auch deshalb, weil es extrem aufwendig ist innerhalb von with für jeden einzelnen Bezeichner festzustellen wozu der gehört

Ist doch eh zweitrangig, wenn es darum geht, Code zu verstehen. Da muss man nicht wissen, woher der einzelne Wert kommt. Wenn Du das wichtig ist, schreibst Du bestimmt auch 'self' vor jeden Bezeichner ;-)

[JamesTKirk]

Zitat:

Zitat von Furtbichler (Beitrag 1227484)

Ich verwende 'with', wenn es mir in den Kram passt, nicht nervt und mich nicht konfus macht. Es gibt Strukturen, die sind enorm komplex und da ist ein 'with' hilfreich und fördert die Übersichtlichkeit.

Sehe ich genauso. :)

Zitat:

Zitat von Furtbichler (Beitrag 1227484)

Blöd wird es beim Debuggen, aber solange das, was ich da schreibe, unwichtig ist, soll es mir doch recht sein.

Der Debugger in Lazarus mag zwar oft zurecht als schlecht im Vergleich zum Delphi Debugger bezeichnet werden, aber mit Bezeichnern, die über ein

Delphi-Quellcode:

with

reinkommen, kann er umgehen :mrgreen: (solang es keine komplexen Properties sind... dann gilt der erste Teilsatz wieder...)

Gruß,
Sven

[Furtbichler]

Zitat:

Zitat von JamesTKirk (Beitrag 1227520)

...aber mit Bezeichnern, die über ein

Delphi-Quellcode:

with

reinkommen, kann er umgehen :mrgreen:

Somit ist wohl bewiesen, das nicht das 'with' der Bösewicht ist, sondern der blöde Debugger von Delphi.

[jaenicke]

Zitat:

Zitat von Furtbichler (Beitrag 1227527)

Somit ist wohl bewiesen, das nicht das 'with' der Bösewicht ist, sondern der blöde Debugger von Delphi.

Klar könnte man dem Debugger mehr beibringen. Da gibt es noch ein paar andere Themen. Zum Beispiel Variablen, deren Wert beim Durchklicken durch den Stack in der Liste mit lokalen Variablen angezeigt wird, aber nicht per Mouseover.

Aber with ist so ca. das letzte was ich als wichtige Änderung im Debugger betrachten würde. Wer das nutzt, der muss dann eben auch damit leben, dass nicht alle entstehenden Probleme kaschiert werden.