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. :stupid:

[hanspeter]

Zitat:

Zitat von Lemmy (Beitrag 1082321)

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:

Zitat von himitsu (Beitrag 1082324)

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. :stupid:

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:

Zitat von hanspeter (Beitrag 1082326)

[
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. :stupid:

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 :angle2: ).

[WM_CLOSE]

Ich würde sagen, dass TObject neben den anderen Typen, die im Compiler eingebaut sind oder in der System.pas stehen nicht VCL ist.
Feststellen was zur VCL gehört, kann man z.b. indem man mal in dern Ordner ...\CodeGear\RAD Studio\6.0\source\Win32\vcl reinschaut. alles was zur VCL gehört ist da drin. fertig.
TObject gehört folglich zur RTL.

[Florian Hämmerle]

Es gibt von Delphi zu Oxygene ja den Oxidizer, der die notwendigen umstellungen vornimmt (kleine Hangemachte Änderungen natürlich vorbehalten ;)). Es wird sicher auch etwas in der Art für Cooper geben denke ich. Allein um die Portierung attraktiver zu machen...

mfg Florian

[hanspeter]

Das was ich meine hat eigentlich mit der VCL noch gar nichts zu tun. Es geht um die moderneren Sprachkonstructe in der Prism-Linie.
Delphi als Pascaldialekt standardisiert.
Mit den Tools Oxidizer und ShineOn kann ich Delphi Quelltext mehr oder weniger zu Prism Quelltext konvertieren/verwursteln.
Die Unterschiede liegen auf Sytaxebene.
Syntaxvergleich
Beispiel :
- Zusätzlich zu procedure und function noch method, erweiterte Definitionsmöglichkeiten für propertys, Case mit Stringvartiable, Delegates.
Wobei hier natürlich plattformspezifische Besonderheiten auf Win32/Win64 keinen Sinn machen.
Letztendlich stände dann unter Delphi ein sprachkompatibler Subset bereit.
Das man die GUI auf jeder Plattform mehr oder weniger neu machen muss, zumindest zur Zeit, ist eigentlich klar.
Der Kauf von KSDev durch Embacadero läßt hier aber auch auf neue Lösungen hoffen, die hoffentlich Systemübergreifend sind.

Peter

[Florian Hämmerle]

Dann stell dir jetzt mal vor, was passiert wenn von heute auf morgen Delphi (Win32) nur noch method kennt und kein function /procedure mehr.
Alle größeren Projekte wie JVCL/JCL werden sich erst mal bedanken und uns dann viel Glück wünschen. Was sagen die ganzen Firmen, deren Softwarepakete nicht mehr mit einer neueren Version kompilierbar sind?

Sicher wäre es schön, wenn es eine gemeinsame Syntax gäbe, aber das hat sich in all den Jahren nie herauskristallisiert (außer damals, als es noch Delphi.NET gab, das wenn ich mich recht entsinne, n totaler reinfall wurde?? ;))

Delphi für Windows, Linux, Mac soll gemeinsame Syntax haben. Prism soll seine behalten, da sie optimal auf .NET zugeschnitten ist. Cooper hat auch die Feinheiten von Java denke ich mal was ich so gelesen / gehört habe. Passt doch alles so wie es ist.
Sollte Android im Tablet / Desktop Bereich einmal so stark werden dass es sich lohnt, ganze Anwendungen wie zum Beispiel Office darauf laufen zu lassen, ist es vielleicht an der Zeit Android in die Kategorie Windows / Linux / Mac aufzunehmen und die gleiche Syntax zur Verfügung zu stellen.

mfg Florian

[Bummi]

Ich denke ein One Fits all muss zwangsläufig auf die Performance durchschlagen, letztlich landet man bei einem "interpretierten" Kompromiss. Ich würde eine strikte Trennung zwischen VCL und Prism u.ä. präferieren.

[mkinzler]

Nicht wenn statt Vererbung/bedingter Code ein Codegenerator verwendet werden würde

[hanspeter]

Zitat:

Zitat von Florian Hämmerle (Beitrag 1082382)

Dann stell dir jetzt mal vor, was passiert wenn von heute auf morgen Delphi (Win32) nur noch method kennt und kein function /procedure mehr.

mfg Florian

Wer hat gesagt nur noch? Das das nicht geht, ist mir klar.
Im Prinzip könnten solche Konstrukte parallel bestehen.
Ich stehe im Moment halt vor der Entscheidung ein großes Projekt mit Delphi oder Java zu beginnen.
Mit dem was in Delphi zu erwarten ist, könnte ich den gleichen Plattformumfang abdecken, wie mit Java.
Mit Blick auf "Altlasten" und Personal wäre das interessant.
Nicht aber wenn ich den gleichen, eigentlich Plattform unabhängigen Quelltext der "Workerklassen" parallel in zwei oder drei Pascaldialekten pflegen muss.

Peter

[Florian Hämmerle]

Cooper und Oxygene sollen ja von der Syntax her gleich sein. bei Cooper ist bspw. LINQ nicht dabei (würd ja auch keinen großen Sinn machen), dafür sind kleine dinge dabei. Die Änderungen sollten sich also in grenzen halten.
Was mit dem original-Delphi geschieht wird man erst noch sehen was geschieht. vielleicht kann da ja jemand mit guten kontakten zu Emba mal ein Statement abgeben was die Syntax betrifft.

mfg Florian

[WM_CLOSE]

Ich persönlich denke, dass man tatsächlich darauf verzichten sollte diese diversen Altlasten ständig mitzuschleppen. Delphi hat einen komplett anderen Einsatzzweck wie Prism. man sollte das eigentlich strikt trennen.
Delphi ist und bleibt eine IDE für Win32. Und Prism ist Prism:twisted:
wenn es sich durchsetzt Anwendungen auf Prism anstatt Delphi zu entwickeln, dann stirbt Delphi halt.
Genauso umgekehrt.
Warum sollte man ständig auf Vorteile von Neuem verzichten nur weil man kompatibel zu dem Alten zu sein will (und am Ende erst nicht ist).
siehe: http://www.scheissprojekt.de/spezifikationen.html