Delphi 13 Florence wurde veröffentlicht

[DevidEspenschied]

Liebe Community,

da viele Delphi-Fragen zum Produkt und Inhalt aufgetreten sind, habe ich diesen neuen Thread erstellt und erläutere gerne die Lösungen und Antworten.

Es gab einen Thread in dem gesagt wurde, dass Delphi 13 keine neue Versionsnummer rechtfertigt - darauf kann man unterschiedlich reagieren, was der Thread ja auch gezeigt hat. Thomas hat diesen Thread geschlossen. Nichtsdestotrotz möchte ich das Thema nochmal auf fachlicher Ebene aufgreifen.

Grundsätzlich wurde das bisherige für viele nicht zufriedenstellende Refaktoring entfernt. Empfohlen wird als wesentlich überlegenerer Ansatz der MMX Code Explorer, der von Uwe Raabe gepflegt wird und unter www.mmx-delphi.de beziehbar ist.

Die Tastenkombination Strg+Alt+Shift+P synchronisierte die Interface- und Implementation-Versionen ihrer Prozedur- und Funktionsprototypen, und war ebenfalls Teil des entfernten Refaktorings. Mit installiertem MMX lässt sich über Strg+Alt+Y die gleiche Funktionalität erreichen (Sync Declaration/Implementation).

Den Code-Formatierer hat Embarcadero ebenfalls aufgrund vieler Probleme entfernt und empfiehlt hierfür "pasfmt", wobei es sich um eine Rust-Lösung handelt, die mit einem RAD Studio PlugIn in die IDE integrierbar ist (pasfmt-rad). Es wird daran gearbeitet, dieses Tool demnächst über GetIt bereitzustellen.

Viele Grüße,
Devid

[dummzeuch]

Ob ein Formatter, der kaum Konfigurationsmöglichkeiten bietet, ein guter Ersatz ist? Naja, betrifft mich ja nicht wirklich ...

[DeddyH]

Also, wenn in meiner Firma ein Feature nicht richtig funktioniert, wird zumindest versucht, es zu fixen. Unsere Kunden würden uns aufs Dach steigen, wenn wir sagen würden "das funktionierte nicht richtig, daher haben wir es entfernt". Sollten wir das dann doch tun, würden wir uns über einen gewissen Unmut nicht wundern. Und wenn einem dann noch gesagt wird, nimm doch die Alternativen von Fremdprogrammierern, dann stellt sich einem schon die Frage, wieso man dann nicht gleich die IDE von anderen Anbietern verwenden sollte, zumal die oft günstiger oder gar kostenlos sind. Zumindest bei mir persönlich hat Emba in den letzten Jahren massiv Vertrauen verspielt, aber ich bin kein Entscheidungsträger.

[DevidEspenschied]

Zitat von DeddyH:

Also, wenn in meiner Firma ein Feature nicht richtig funktioniert, wird zumindest versucht, es zu fixen. Unsere Kunden würden uns aufs Dach steigen, wenn wir sagen würden "das funktionierte nicht richtig, daher haben wir es entfernt". Sollten wir das dann doch tun, würden wir uns über einen gewissen Unmut nicht wundern. Und wenn einem dann noch gesagt wird, nimm doch die Alternativen von Fremdprogrammierern, dann stellt sich einem schon die Frage, wieso man dann nicht gleich die IDE von anderen Anbietern verwenden sollte, zumal die oft günstiger oder gar kostenlos sind. Zumindest bei mir persönlich hat Emba in den letzten Jahren massiv Vertrauen verspielt, aber ich bin kein Entscheidungsträger.

Die Funktionen für Refactoring und Codeformatierung hatten einen Punkt erreicht, an dem es nicht mehr möglich war, diese Funktionen aufrechtzuerhalten, und Embarcadero hatte aus verschiedenen Gründen keine andere Wahl, als sie zu entfernen. Ian Barker wird in der nächsten Woche einen Blogbeitrag und ein Video dazu veröffentlichen und die empfohlenen Alternativen vorstellen.

Embarcadero beabsichtiget, die Funktionen in einer zukünftigen Version wieder einzuführen, kann jedoch zum jetzigen Zeitpunkt noch keinen Zeitplan dafür nennen. Vorläufig bleibt der Menüpunkt beibehalten, für den Fall, dass Optionen von Drittanbietern hinzugefügt werden (nicht empfohlen), und auch, weil er in RAD Studio für C++Builder-Anwendungen, die einen anderen Refactoring-/Formatierungsmechanismus verwenden, weiterhin relevant ist.

Derzeit wird Delphi-Entwicklern die Verwendung des hervorragenden MMX Explorers von Uwe Raabe empfohlen. Er verfügt über zahlreiche Refactoring-Funktionen, die über die der alten integrierten Funktionen hinausgehen.

[Cypheros]

Ehrlich gesagt habe ich mich noch nie bei Borland, Inprise oder Embarcadero wegen irgendwas beschwert in den letzten 25 Jahre aber ich habe zum ersten mal an Marco geschrieben, dass die Entwicklung rund um das Refactoring für mich absolut nicht akzeptabel ist. Wie sich hier ja gezeigt hat, bin ich nicht der einzige Entwickler, der so denkt.

Nicht nur hat man über die letzten Jahre das Refactoring vollkommen vernachlässigt und nicht an die neuen Sprachfeatures angepasst, wodurch es immer unzuverlässiger wurde, es nun aber komplett wegzulassen, ist meiner Meinung nach ein vollkommen falsches Zeichen.

Die Probleme mit dem Refactoring sind ja seit vielen Jahren bekannt und ich hätte hier einen Fix für die Probleme oder ein Lösung erwartet, bei der ein neues Refactoring das alte ablöst und nicht eine Version 13, die plötzlich ganz ohne Refactoring da steht.

Alternatives Beispiel aus der Autobranche:
Die Navigation im neuen VW-Model haben wir weggelassen, da sie ja bei den vorherigen Modellen auch nicht wirklich zuverlässig funktionierte. Nehmen sie doch einfach TomTom oder noch besser Google-Maps, das ist sogar kostenlos. Aber ansonsten ist das neue Model super und hat sogar ein beleuchtetes Bremspedal, falls sie mal im Dunkeln bremsen müssen.

Auf kostenlose Fremdprodukte zu verweisen ist nichts anderes als eine peinliche Ausrede für die Tatsache, dass hier eine wichtige Funktionalität verloren gegangen ist.

Ich soll ich mein Portemonnaie aufmachen für ein Produkt, dass weniger kann, als das alte?

Sorry, da spar ich mir die teure Substitution lieber, für die ich über viele Jahre sehr viel Geld bezahlt habe, bis die offensichtlichen Mängel behoben worden sind und Delphi wieder auf dem richtigen Kurs ist.

[jaenicke]

Zitat von DevidEspenschied:

Empfohlen wird als wesentlich überlegenerer Ansatz der MMX Code Explorer

Meinst du mit überlegen, dass er funktioniert? Dann stimmt das. Von der Funktionalität her, wenn sie denn in Delphi funktionieren würde, kann MMX aber wesentlich weniger. Das fängt beim Extrahieren eines Interfaces an, geht über das Umbenennen eines Elements über alle Units hinweg (nicht nach Name, sondern korrekt) bis z.B. zu sicherem Löschen.

Dazu kommt dann noch so etwas wie Oberklasse extrahieren oder Member verschieben usw., das aber bei mir in keiner Delphiversion funktioniert hat, weder z.B. in Delphi 2006, 2007, XE oder 10.4. Aber zumindest waren die Menüeinträge da...

Und beim Extrahieren einer Methode deklariert MMX die Parameter z.B. standardmäßig als var-Parameter, egal ob es nötig ist. Das hat Delphi nur gemacht, wenn es nötig war.

Ich hoffe, dass irgendwann noch ein echtes Refactoring basierend auf dem LSP kommt, wie es Marco mal für die fernere Zukunft gesagt hatte...

[himitsu]

Nunja, im Grunde wurde "nur" das uralte, schrottige und kaum funktionierende Modelling entfernt, was eh mehr Probleme bereitete, als es nützte. (sorgte ständig dafür, dass die IDE abstürzte oder unerträglich langsam wurde, selbst wenn man es gar nicht benutzte)

Und der Formatierer war nur ein kleines Nebenopfer. (wobei der ja auch genug Macken hatte, die nie behoben wurden, und er immer mehr der hauseigenen neuen Code-Features garnicht verstand)

[Uwe Raabe]

Zitat von jaenicke:

Das fängt beim Extrahieren eines Interfaces an

Was genau fehlt denn bei Extract Interface?

Zitat von jaenicke:

geht über das Umbenennen eines Elements über alle Units hinweg (nicht nach Name, sondern korrekt)

Ja, das ist bekannt.

Zitat von jaenicke:

bis z.B. zu sicherem Löschen.

Was genau meinst du denn damit?

Zitat von jaenicke:

Dazu kommt dann noch so etwas wie Oberklasse extrahieren

Auch hier wäre ich für eine genauere Beschreibung dankbar. Welche Funktionalität müsste bei Extract Class dazukommen?

Zitat von jaenicke:

oder Member verschieben

Refactorings -> Move to?

Zitat von jaenicke:

Und beim Extrahieren einer Methode deklariert MMX die Parameter z.B. standardmäßig als var-Parameter, egal ob es nötig ist.

Guter Punkt. Die Frage ist hier dann, wonach entscheidet man ob es nötig ist? Ich vermute, man muss analysieren ob die Variable im Extract verändert und im darauf folgenden Code verwendet wird?

So ganz allgemein stelle ich mir allerdings die Frage: Warum sind mir solche Dinge nicht schon viel früher zugetragen worden? Bugs and Features

[jaenicke]

Zitat von Uwe Raabe:

Zitat von jaenicke:

Das fängt beim Extrahieren eines Interfaces an

Was genau fehlt denn bei Extract Interface?

Ehrlich gesagt wusste ich nicht, dass es das gibt, ebenso wie das Extrahieren aus einer Klasse, weil ich es nicht bei den Membern vermutet hatte und es daher schlicht übersehen habe. Das funktionierte bei Delphi ja so, dass man die Klasse markiert hat, den Befehl aufgerufen hat, die Member ausgewählt hat, das Interface benannt hat und Delphi dieses Interface dann deklariert und bei der Klasse als implementiertes Interface eingetragen hat.

Zitat von Uwe Raabe:

Refactorings -> Move to?

Das habe ich nie gebraucht und eben nicht gefunden, als ich die Funktionen verglichen habe. Mein Fehler.

Zitat von Uwe Raabe:

Zitat von jaenicke:

bis z.B. zu sicherem Löschen.

Was genau meinst du denn damit?

Die entsprechend benannte Funktion in Delphi hatte vor dem Löschen geprüft, ob das Element irgendwo verwendet wird.

Zitat von Uwe Raabe:

So ganz allgemein stelle ich mir allerdings die Frage: Warum sind mir solche Dinge nicht schon viel früher zugetragen worden? Bugs and Features

Weil ich MMX zwar für das Editieren von Elementen usw. verwendet habe (wobei es schön wäre, wenn man auch mehrere parallel editieren könnte, ja, kann ich als Featurewunsch eintragen), für echtes Refactoring aber nicht als Ersatz gesehen habe. Denn meiner Meinung setzt das voraus, dass der Gesamtzusammenhang im Projekt verwendet wird (Compiler, LSP) und nicht "nur" auf einem Syntaxbaum einer Unit gearbeitet wird, was MMX angesichts des Umbenennens ja vermutlich tut.

[Uwe Raabe]

Vielleicht sollte ich dich anpingen wenn mal ein neuer MMX Workshop ansteht?

Zitat von Uwe Raabe:

Die entsprechend benannte Funktion in Delphi hatte vor dem Löschen geprüft, ob das Element irgendwo verwendet wird.

Da sind ja die technischen Voraussetzungen identisch mit dem Unit-übergreifenden Umbenennen. Ich werde das mal mit in das Epic Code Model aufnehmen.