In neuen Lazarus Projekten fehlt mir dort gar nichts, was das leben in Delphi angeblich so unnachahmlich besser macht
Debuggen und komplexe verschachtelte Objekte inspekten musst du vermutlich in deinen Projekten nicht?
Durchaus debugge ich da ziemlich komplexe Objekte und reichlich TList instanzen, die damit gefüllt sind, aber auch da ist der code, der von mir selbst geschrieben wurde, keinewegs so verschachtelt, das ich damit eine eigene
vcl noch mal irgendwo oben drauf bau, bei dem mir schon die basisobjekte suspekt sind.
Meine objektklasssen gehen in der regel auf Ebene TObject los und selten auch mal banal erweiterten TWinControls o.ä..
Abstruse Ableitungen zum Beispiel von TDatasets auf mehreren Ableitungsebenen hab ich schon oft als consultant gesehen und es gruselt mich, wenn mir da jemand erst mal lang und breit erklären muss, warum der da wo in welcher code ebene zB Haltepunkte setzt und der dann trotzdem nicht aktv ist, weil der Entwickler wieder irgendeine Zwischeneben vergessen hat.
Und mit irgenwelche späteren Updates der Basisklassen zB durch neuen delphi/
vcl version liefern fehler, die man erst mal finden muss, weil die ggf erst nachträglich den eigenen Code inkompatibel machen.
Das liegt aber auch daran, das eine Anwendungsarchitektur bei mir zum großen Teil auf dynamische Interpretation von Datenbankstrukturen basiert.
Dafür hab ich mir relativ simple Klassen gebaut und die in den letzen 25 Jahren erst mit Delphi später dann mit Lazarus immer mehr erweitert hab, aber weiterhin auf der selben architektur basieren, die vom code her weiterhin mit allen delphi und lazarusversionen compilierbar und benutzbar sind.
Aber zurück zum debuggen: wenn ich irgendwo in meinem code haltepunkte setze, werte auswerten möchte, aufrufstack überwachen will oder bedingungen für die haltepunkte setze, mit F7 oder F8 step by step weitergehen will, funktioniert das bei mir in lazarus einwandfrei. Empfinde ich daher für meine Ansprüche keineswegs als einschränkend. Nicht immer sind funktionale Einschränkungen im Werkzeug begründet, der selbst geschrieben code ist oft teil des Problems.
Ich versuche aber schon immer, meinen Pascalcode einfach zu halten und erzeuge sowieso nahezu alles an visuellen kram auch nur zur Laufzeit. Das hat sich in den letzten 25 Jahren immer bewährt.
wie sagte schon Hannibal lector: "Oberste Prinzipien Clarice. Simplifikation"