Das von mir genannte Beispiel in den VirtualTrees war:
Delphi-Quellcode:
with DrawRect do
MaskBlt(Target.Handle, Left - Offset.X, Top - Offset.Y, (Right - Offset.X) - (Left - Offset.X),
(Bottom - Offset.Y) - (Top - Offset.Y), Source.Canvas.Handle, Left - PicRect.Left, DrawRect.Top - PicRect.Top,
Source.MaskHandle, Left - PicRect.Left, Top - PicRect.Top, MakeROP4(DST, SRCCOPY));
Aber Offset gibts halt nun seit XE2 auch in TRect, so dass nicht mehr die Eigenschaft Offset, sondern DrawRect.Offset vom Compiler versucht wurde zu benutzen.
Und solche Erweiterungen kann man eben in fremden Quelltexten, die man benutzt nicht vorhersehen. Deshalb birgt with eben immer nicht nur die Gefahr, dass man selbst etwas verwechselt, sondern eben auch, dass Änderungen an ganz anderer Stelle plötzlich Probleme machen.
Solange es dann einen Compilerfehler gibt wie hier, ist das nur ärgerlich. Aber wenn der Dateityp dann an einer solchen Stelle übereinstimmt, wünsche ich viel Spaß beim Suchen des Fehlers, wenn man doch z.B. nur eine externe Komponente aktualisiert hat...
Ich hatte genau das Problem schon mehrfach in fremden Quelltexten. Und das nervt einfach nur tierisch, wenn man dadurch dann Stunden verschwendet, nur weil jemand nicht ordentlich programmiert hat.
Wir haben in der Firma jedenfalls with aus dem Wortschatz gestrichen.
Aber am allermeisten nervt daran, dass ein schnelles Debuggen mit with praktisch unmöglich ist. Keine Mouseoverauswertungen, Strg + F7 nur mit zusätzlicher Tipparbeit, ...
Aber weder das eine noch das andere wird erzwungen, und wenigstens den warnenden Hinweis wegen dieser problempotentiellen doppelten Gleichbezeichnung hätte ich mir bei diesem sehr ausgereiften Compiler noch gewünscht.
Wenn der Compiler einen mehrdeutigen Bezeichner findet, warnt er auch. Aber er sucht nicht zusätzlich in weiter entfernteren Scopes nach mehrdeutigen Bezeichnern, denn das würde die Kompilierzeit logischerweise erhöhen, wenn z.B. nach jeder lokalen Variable überall gesucht werden würde...