Interview mit Danny Thorpe über Delphi 8
Danny Thorpe
Compiler Architect, RAD Tools Group, Borland Software Corp.
Interview vom Juli 2003; die Fragen stellte Martin Strohal
Delphi-Treff: Hallo Danny, was ist Ihre Aufgabe bei Borland?
Danny Thorpe: Ich bin der technische Lead Engineer für die Delphi-Compiler (Linux, Win32 und jetzt .NET) und Laufzeitbibliotheken. Ich habe die letzten zwei oder drei Jahre hauptsächlich am Inneren des Compilers gearbeitet, aber ich überblicke auch das Innere der RTL und das Innere der VCL. Das „Innere der VCL“ bedeutet, dass ich mich nicht daran erinnere, wie jede bestimmte Komponente arbeitet, aber ich kann Ihnen sagen, wie alle Komponenten arbeiten! :>
Meine offiziellen Titel sind „Borland .NET Architect“ und „Compiler Architect, RAD Tools Group“.
Wird es wichtige Änderungen am Delphi-Compiler in Version 8 geben?
Ja, auf jeden Fall! Wir verwenden .NET als einen Katalysator für Änderungen: Wir erweitern viele Bereiche der Delphi-Sprache, so dass Delphi for .NET alle Aspekte der .NET-Plattform vollständig umfassen kann. Delphi kann .NET-Objekte verwenden und von ihnen erben, und andere .NET-Sprachen können Delphi-Objekte verwenden und von ihnen erben, völlig transparent. Keine weiteren Header-Übersetzungen mehr!
Viele dieser Sprachverbesserungen werden auch im Win32-Delphi-Compiler verfügbar sein. Dinge wie statische Klassenfelder, Klassenattribute, strict private und strict protected Sichtbarkeiten und vieles andere kann ohne die .NET-Plattform implementiert werden. Wir wollen keine komplexen Monster wie garbage collected Speichermanagement in Win32 implementieren, aber wir versuchen, die Delphi-Syntax zwischen Win32 und .NET so nah wie möglich zusammen zu halten.
Simon Thornhill schrieb in seinem offenen Brief an die Delphi-Entwickler, dass Delphi 8 sowohl Win32 als auch .NET unterstützen wird. Wird beides in einer einzigen IDE integriert sein?
Ja, der Plan ist, eine einzige IDE zu haben, die die Entwicklung sowohl von Win32- als auch von .NET-Anwendungen unterstützt. Unter der Haube bedeutet das, dass die IDE zwei unterschiedliche Compiler kennen muss (dcc32 und dccil), zwei unterschiedliche Debugger (für Win32 und für .NET-Code) und mehrere Komponentenframeworks (Win32-VCL, .NET WinForms und VCL for .NET).
Das klingt kompliziert, aber alles, womit ein Delphi-Programmierer umgehen muss, sind drei Menüpunkte: Datei/Neue Win32-Anwendung, Datei/Neue .NET-WinForms-Anwendung und Datei/Neue VCL for .NET-Anwendung. Wenn man ein bestehendes Delphi-Projekt öffnet, wird die IDE selbst herausfinden, welches Toolset aktiviert werden muss, um mit diesem Projekt zu arbeiten.
Sind viele Änderungen am Quellcode nötig, um eine .NET-Anwendung zu erzeugen?
Wie bei jedem Plattformwechsel wird es einige Quellcodemuster geben, die aktualisiert werden müssen, um eine bestehende VCL-Anwendung nach VCL for .NET zu portieren. Für „normalen“ „sauberen“ Delphi-Anwendungsquellcode sollten die Änderungen sehr geringfügig sein. Anwendungscode, der auf Delphis eingebaute Typen, RTL-Funktionen und Methoden und Eigenschaften von VCL-Komponenten basiert, wird ziemlich leicht nach .NET zu portieren sein. Anwendungscode, der sich stark auf fragliche Typecasts, lowlevel Zeigermanipulation, absolute Variablen oder andere schmutzige Tricks stützt, wird nicht so einfach nach .NET zu portieren sein.
Bestehende Delphi-Forms (DFM-Dateien), die allgemeine VCL-Komponenten (Buttons, Checkboxen, Grids usw.) verwenden, sollten sich ohne große Probleme nach .NET portieren lassen. Formulare, die hauptsächlich Komponenten von Drittherstellern verwenden, benötigen eine vergleichbare Komponente auf .NET-Seite, um die Migration zu vervollständigen.
VCL-Komponenten leben näher an der Plattform als Delphi-Anwendungscode, deshalb kann das Portieren Ihrer VCL-Komponentenquellcodes nach .NET etwas mehr Nachdenken erfordern als bei Anwendungscode. Vor allem ist es wahrscheinlicher, dass Komponenten empfindlich auf Ressourcenmanagementdinge wie Speicherzuweisung, Datei- und Win32-Handle-Management und Komponenten-Destruktor-Ausführung reagieren. .NET’s Garbage Collection macht das explizite Freigeben von Objekten in den meisten Fällen überflüssig und benötigt verschiedene Techniken, um Speicher für String-Buffers oder andere Nicht-Objekt-Daten zu allozieren.
Destruktoren sind in .NET ziemlich verschieden. Die gute Nachricht ist, dass die meisten Gründe, weshalb Sie heute in der Win32-VCL Destruktoren implementieren (um allozierte Objekte freizugeben), in .NET nicht länger relevant sind – die Objekte, die Sie im Konstruktor Ihrer Komponente allozieren, werden freigegeben, sobald sie nicht mehr verwendet werden. Die schlechte Nachricht ist, dass Ihre Destruktoren in .NET nicht unbedingt ausgeführt werden, wenn Ihre Komponenten in Nicht-Delphi-Code verwendet werden. In VCL for .NET-Anwendungen ist dieser Unterschied nicht beachtenswert (weil die VCL die Komponenten-Destruktoren aufrufen wird), aber es ist wichtig, daran zu denken, wenn Code geschrieben wird, den Sie planen, an Nicht-Delphi.NET-Nutzer weiterzugeben.
Obwohl .NET-Objekte automatisch freigegeben werden, wenn Sie nicht länger von „lebendem“ Code referenziert werden, wird das „Create / try / finally / free“-Muster auch weiterhin beim Schreiben von Delphi for .NET-Code empfohlen. Dieses Muster hat in .NET keine schlechten Effekte, bietet aber den Nutzen, Legacy-Destruktoren auszuführen und den Win32-Code kompatibel zu halten.
In deutschen Magazinen gibt es Gerüchte, dass Sie Probleme damit haben, die VCL an .NET anzupassen. Deshalb wird Delphi 8 erst am Jahresende veröffentlicht. Ist das richtig? Wie sicher ist das Release-Datum?
Ich erinnere mich nicht daran, bei der Implementierung von VCL for .NET auf bedeutsame, planbedrohliche Probleme gestoßen zu sein. Es war ziemlich leicht, die VCL nach .NET zu portieren, als der Großteil des Delphi-Sprachsupports im Compiler implementiert war. Herauszufinden, wie die Reichhaltigkeit der Delphi-Sprache über .NET zu implementieren ist – das war zu der Zeit eine Herausforderung!
.NET Common Language Runtime (CLR) und Common Type System (CTS) definieren sehr spezifische Regeln darüber, wie Typen definiert werden können und wie sie interagieren. Die CLR hat kein Konzept einer virtuellen Klassemethode (static) oder eines Klassenreferenztyps, weshalb wir herausfinden mussten, wie wir diese mächtigen Konzepte oberhalb der CLR implementieren konnten. Wie Sie vielleicht wissen, benötigt das Laden eines Formulars und seiner Komponenten aus einer DFM-Datei zur Laufzeit das Erzeugen der Komponenten, indem ein virtueller Konstruktor unter Verwendung einer Klassenreferenz aufgerufen wird. Unter VCL for .NET war Formular-Streaming nicht möglich, bis der dccil-Compiler eine Lösung für Klassenreferenzen hatte.
Ein anderes schwieriges Problem war die Implementierung des Delphi-Variant-Typs in der typstrengen .NET-Umgebung. (.NET setzt den Win32-Datentyp OleVariant nicht in .NET-Code um.) Die Datenflexibilität des Variant-Typs geht größtenteils auf Kosten der Komplexität für den Compiler und die RTL. So gerne ich Dinge auch loswerden würde, die uns ständig Probleme bereiten, sind Varianten ein sehr mächtiger generischer Datenumschlag und kritisch für Delphis Datenbankklassen.
Wir haben einige verschiedene Ansätze durchgespielt, um Varianten zu implementieren, und unsere neueste Bemühung sieht sehr nach einer soliden, langfristigen Implementierung aus. Diese neue Lösung in wirklichem Delphi-Stil ist eine Mischung aus Compiler-Magic und RTL-Support-Code. Ich denke, dass Delphi-Profis *sehr* aufgeregt sein werden, wenn sie die neue Varianten-Implementierung sehen werden – nicht wegen der Variants an sich, sondern wegen der .NET-Techniken, die wir während der Zähmung des Variant-Biests gelernt und entwickelt haben.
Ich bin zuversichtlich, dass die Delphi-Spracherweiterungen für den dcc32-Compiler und den neuen dccil-Compiler und die zugehörigen RTLs und VCLs zum Zieltermin, den ich vor über einem Jahr angegeben habe, fertig sein werden. Wann die Produktboxen in den Ladenregalen stehen werden, wer kann das sagen? Eine Entwicklungstoolsuite erfordert viel mehr als nur einen Compiler. Das Produkt wird ausgeliefert werden, wenn wir die richtige Konvergenz vieler Technologien erreichen.
Was wird in Delphi 8 außerdem wichtig sein?
Ich vernehme, dass viel Arbeit dahin geht, den Borland Application Lifecycle Management-„Stapel“ von TogetherSoft-, StarTeam- und Bold MDA-Technologien in die Delphi 8-IDE zu integrieren. Ich weiß nicht viel über Details, da der ALM-Stapel viele, viele Schichten über meiner Domäne, dem Compiler, ist.
Wie wichtig ist Delphi für Borland im Vergleich zum C++-Builder (BCB), zum JBuilder und dem neuen C#-Builder?
Delphi ist Borlands Nr. 1-Werkzeug für Win32-Anwendungsentwicklung und stellt einen bedeutsamen Teil von Borlands jährlichen Einnahmen und der Kundenbasis dar. Wie rivalisierende Geschwister wetteifern der JBuilder und die Delphi+BCB-Produktlinie regelmäßig um hohe Ehren in den Quartalseinnahmen, wobei der Sieg normalerweise an das Team mit dem zuletzt zurückliegenden Produktrelease (oder den niedrigsten operativen Kosten!) geht. C#Builder ist gerade erst am Markt gestartet und soll viele neue Kunden in das Borland-Lager bringen.
Einige Delphi-Win32-Fans haben ihre Befürchtung ausgedrückt, dass all die Entwicklungsanstrengungen für Delphi for .NET Ressourcen von der Delphi for Win32-Entwicklung abziehen. Weit gefehlt! Wir nehmen .NET zum Anlass, um die Delphi-Sprache auf allen Plattformen weiterzuentwickeln – .NET, Win32 und später Kylix genauso.
Die Delphi-Sprache durchläuft Phasen schrittweiser Evolution, punktuiert durch gelegentliche Ausbrüche explosiven Wachstums.
Wir sind in der Mitte einer Supernova der Delphi-Sprachevolution.
Vielen Dank für die Beantwortung unserer Fragen!