Wie weiter mit Delphi als Sprache

[hanspeter]

Delphi selbst wurde von Borland als quasi-Sprachbezeichnung für einen eigenen Pascaldialekt eingeführt.
Der Dialekt wurde nie standardisiert, wo zu auch.
Mit Delphi selbst hat dieser Standard über Jahre stagniert und wurde nur sehr zögerlich und teilweise halbherzig weiterentwickelt.
Mit den Generics z.B. hat sich die ganze Listensortierung deutlich kompliziert.
Im Moment sieht es so aus das es unter der Haube von Embacadero zwei Sprachstandards für die Sprache Delphi gibt, die nicht voll kompatibel sind.
Die Situation ist dadurch entstanden, das Emb. Oxygen von Remobjects als Prism in das Label Delphi übernommen hat.
Oxygen hat einen wesentlich moderneren Sprachdialekt.
Inzwischen kommt wieder Bewegung in die Delphientwicklung und es zeichnet sich ab, das es für das Produkt Delphi wieder einige Alleinstellungsmerkmale geben kann.
Remobjects hat einen Sprachcompiler für die JVM angekündigt/vorgestellt und ein Compiler für Android geistert auch schon durch den Raum.
Unklar ist, ob diese neuen Compiler von Remobjects direkt oder unter dem Label Delphi von Embacadero mit vertrieben werden.
Von Embacadero selbst steht der Win64 Compiler vor der Tür und eine Lösung für Mac und Linux ist wohl auch zeitnahe in der Pipline. Damit hätte man mit Delphi als Sprache Möglichkeiten, welche kaum ein anderes Entwicklungssystem bietet. Die Entwicklung für 3 gemanagte Framworks und 3 Betriebssysteme mit einer Sprache.
Hier wäre es nach meiner Meinung dringend notwendig den Sprachstandard dieser Entwicklungslinien zu standardisieren. Zumindest auf Quelltextebene sollten alle Dialekte
voll kompatibel sein, sodaß man den gleichen Quelltext/Klassendefinition (so VCL frei) in allen Compiler-Varianten einbinden kann.
Wenn man sich jetzt entscheidet ein größeres Projekt wieder mit Delphi zu beginnen, dann könnte man die Workerklassen jenseits der VCL mit dem moderneren Sprachstandard unter Prism entwickeln, in der Hoffnung diese irgendwann unter Win32 oder Win64 mit einbinden zu können.

Interessant wäre, ob es Überlegungen in dieser Richtung gibt, oder liege ich mit dieser Erwartung falsch?

Gruß
Peter

[Lemmy]

Hallo,

wäre sicherlich interessant, nur Win32/64 bedeutet halt VCL (TObject IST VCL) und Delphi Prism bedeutet .NET und Cooper (der Delphi-Java- Verschnitt) bedeutet halt Java (also das Java-Framework). Du hast hier unterschiedliche Klassenmodelle die sich so einfach nicht zusammen bringen lassen - Borland hat es mit VCL for .net versucht und ist dabei grandios gescheitert! Ich kann mir ehrlich gesagt nicht vorstellen, dass hier in der Zukunft nochmal ein Versuch unternommen wird.

Grüße

[himitsu]

Zitat:

TObject IST VCL

Nee, TObject ist CL.

VCL fängt eher erst bei TComponent an, wenn man dieses unbedingt auf eine Klasse festlegen will ... wobei, VCL (visual) ist ja erst TWinControl.

[hanspeter]

Zitat von Lemmy:

Hallo,

wäre sicherlich interessant, nur Win32/64 bedeutet halt VCL (TObject IST VCL)

Soweit würde ich ja gar nicht gehen. Unter dem Strich ist mir bei einer Klassendefinition die Vorgängeklasse egal. Es muss nur auf Quelltextebene gleich funktionieren.
Die Ableitung von TObject gebe ich ja explizit nicht an.

Delphi-Quellcode:

type
  TProduktionsoptimierung = class
  private
    Variablenliste
  public
    method ...
  published
  property
end;
// Hier folgen die 5000 Zeilen Code

[Bernhard Geyer]

Vereinheitlichung müsste m.E. dann so getrieben werden das unser "altes, normales" Delphi/Pascal sich Richtung Delphi.Prism entwickelt. Es würde aber auch bedeuten das noch viel mehr alte Kompatiblitäten abgeschnitten werden und die Compilierung von alten Code nochmal nicht funktioniert. Der Aufschrei war ja bei Unicode schon groß (Wieso gibt nicht einen String = AnsiString Schalter), wird bei Win64 groß sein (Wieso ist Int immer noch 4 Byte) und wird groß sein wenn man noch einige ander Zöpfe abschneidet (File of Type stirbt auch uaf Nicht-Managed) oder die Sprache Case-Sensitive machen würde (Compilerwarnungen wegen C++ existieren ja schon lange).

Delphi.Prism anpassen ist schlecht da hiermit die 100% .NET oder bald Java-Kompatiblität gefährtet würde.

[Lemmy]

Hi,

Zitat von himitsu:

Nee, TObject ist CL.
VCL fängt eher erst bei TComponent an, wenn man dieses unbedingt auf eine Klasse festlegen will ... wobei, VCL (visual) ist ja erst TWinControl.

Mengentheorie war noch nie meine Stärke Außerdem ist auch Embarcadero meiner Meinung:

Zitat:

VCL ist die Abkürzung für Visual Component Library, einem Satz visueller Komponenten für die beschleunigte Erstellung von Windows-Anwendungen in Delphi. VCL enthält zahlreiche visuelle und nicht-visuelle Klassen und Hilfsklassen, die Sie bei der Entwicklung von Windows-Anwendungen sowie von Web-, Datenbank- und Konsolenanwendungen unterstützen. Alle Klassen sind von TObject abgeleitet. TObject führt Methoden ein, die grundlegende Verhaltensweisen wie Erstellung, Freigabe und Botschaftsbehandlung implementieren.

Grüße

[Lemmy]

Zitat von hanspeter:

[
Soweit würde ich ja gar nicht gehen. Unter dem Strich ist mir bei einer Klassendefinition die Vorgängeklasse egal. Es muss nur auf Quelltextebene gleich funktionieren.
Die Ableitung von TObject gebe ich ja explizit nicht an.
[DELPHI]type
TProduktionsoptimierung = class

die Kernaussage meines Postings oben hast Du noch nicht gesehen: Die Klassenmodelle VCL-Java-.Net unterscheiden sich trotz mancher Ähnlichkeiten, was ein sinnvolles programmieren unmöglich macht. Deshalb der Verweis auf TObject, da das Delphi TObject sich von den grundlegenden KLassen in Java und .Net unterscheidet. Und je weiter Du im Klassenmodell nach unten gehst desto größer werden die Unterschiede...

Aus dem Grund würde das oben auch nicht sinnvoll funktionieren - außer du fängst an die 5000 Zeilen Code per Compilerdirektiven ein und auszuschalten um die Klasse an die entsprechende Bibliothek anzugliedern....

Grüße

[mkinzler]

Mit reiner Vererbung wird eine Cross-Platform/Cross-Framework Unterstützung nicht gehen. Imho wäre hier Codegenerierung notwendig

TObject gehört m.E. zur Sprache/RTL

[Insider2004]

Wieso besteht hier der Bedarf zu vereinheitlichen? Delphi hat mit Prism und Cooper nichts zu tun. Es sind eigene Ausprägungen. Ich möchte auch nicht, dass die bewährte Sprache Delphi mit C# oder Java-Konstrukten verseucht wird.

Diesen String-Schalter gibt es deswegen nicht, weil Ansi heutzutage "alt" ist. Die Welt ist Unicode. Unicode deckt alles ab und das ohne irgendwelche Code-Tabellen und sonstigem Konvertierungskäse.

[himitsu]

VCL = Frontend

wenn VCL = TObject, dann dürfteman im Backend keine Klassen verwenden,
da man ja Frontend und Backend schön trennen soll.
@Luckie: Du darfst bei deinem NonVCL auch keine Klassen mehr im Programm benutzen ... nichtmal mehr eine TStringList oder ein TStream-Nachfahre, da es dann ja kein NonVCL mehr währe.

IMHO ist VCL (CLX, WinForms usw.) eine Sammlung von Klassen, welche für das schnelle Zusammenklicken im Formeditor verwendet wird und diese Klassen sind typischer Weise von TComponent/TWinControl abgeleitet (OK, implizit zwar auch con TObject, aber das zählt nicht ).