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.

[fisipjm]

Alle bisher genannten Punkte, sehe ich absolut genau so. In einem anderen Thread gab es zu dem Punkt warum es beim Refactoring so schief lief auch nochmal ein bisschen Hintergund wissen, dass recht erhellend für mich war um das ganze technisch besser zu verstehen, die Entscheidungen die daraufhin bei Emba getroffen werden kann ich deshalb trotzdem nicht nachvollziehen.

Das Thema würde ich aber gern noch um einen weiteren Punkt ergänzen, auch wenn der nur recht hypothetisch ist. Ich schätze Uwe als einen Delphianer, der mir entweder direkt oder indirekt durch Beiträge hier im Forum schon mehr als einmal geholfen hat und der durch die Weiterbetreuung des MMX Projekts einen großen Beitrag für die gesamte Delphi Community leistet. Ich weis auch, dass wenn es nach ihm ginge, der MMX schon längst Open-Source wäre.

Und hier kommt mein Punkt:
EMBA möchte mit ihrem RAD Studio ja nicht nur eine IDE sein (in dem ich Refactoring bereits erwarten würde) sondern ein Rapid Application Development Studio. Wenn Uwe nicht so ein netter Kerl wäre, könnte er den MMX von jetzt auf gleich hinter eine Paywall setzen und hätte eine Lizenz zum Geld drucken. Das würde ich ihm ehrlich gesagt sogar gönnen, denn aktuell trägt EMBA ihr eigenes Unvermögen in der technischen und betrieblichen Struktur auf dem Rücken von Entwicklern aus, die nicht auf ihrer Gehaltsliste stehen (und sie somit nichts kosten) ohne auch nur ein bisschen an der eigenen Preisschraube zu drehen.

Ich weis auch, dass Devid an der Stelle nichts dafür kann und als letztes Rad in dem ganzen Konstrukt den Kopf dafür hinhalten muss. Dafür mein größten Respekt und auch dafür, dass du das Thema hier nochmal aufgegriffen hast und dich damit natürlich nochmal dem Unmut der Entwickler stellst. Ich würde mir als Kunde mehr Verbindlichkeit von Seitens EMBA wünschen, weis aber auch von anderer Seite, dass es oft schwer ist das in einem Entwicklungsteam bewerkstelligen zu können. Es wäre schön wenn man es irgendwie schaffen könnte einen 50/50 weg zu finden, aktuell fühlt es sich eher wie 99/1 an.

vG
PJM

[dummzeuch]

Zitat von Cypheros:

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.

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

Es ist ja auch nicht so, dass die neue Version jetzt billiger wurde, weil sie weniger kann, sie ist im Gegenteil wie üblich teurer geworden.

Ich will aber auch mal was positives sagen: Die Delphi 13 IDE scheint mir deutlich stabiler zu sein als die originale Delphi 12 IDE. Die wurde erst mit dem Update 3 verwendbar.

[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