ObjectPascal mit Oxygene verarbeiten

[schöni]

Da frag ich doch gleich mal zu Oxygene:

Die Wiki zeigt jede Menge völlig neue, andersartige (im Vergleich zu Objekt Pascal bis Delphi 2006) Sprchkonstrukte.

Kann denn der Oxygene Compiler auch die von Objekt Pascal schon bekannten Sprachkonstrukte übersetzen?

[Stevie]

Zitat:

Zitat von schöni (Beitrag 1213403)

Da frag ich doch gleich mal zu Oxygene:

Die Wiki zeigt jede Menge völlig neue, andersartige (im Vergleich zu Objekt Pascal bis Delphi 2006) Sprchkonstrukte.

Kann denn der Oxygene Compiler auch die von Objekt Pascal schon bekannten Sprachkonstrukte übersetzen?

Es gibt den Oxidizer, um Delphi Win32 Code in Oxygene kompatiblen Code zu konvertieren. Da wir hier aber von einer Migration von Native zu .Net Code reden, könnte das in der Praxis weitaus komplexer werden als nen simples Konvertieren.

Oxygene ist eine .Net Sprache (ok, eigentlich noch mehr seit Cooper und Nougat), die aber von der Syntax "pascalisch" ist (begin/end statt geschweiften Klammern etc).

Als IDE wird die VisualStudio Shell benutzt, somit hat man schonmal fast alles, was nen Visual Studio so kann zuzüglich der Dinge, die RemObjects noch entwickelt hat (wie z.B. FixIt)

[Daniel]

Spannende Frage, die ich mal vom FreePascal-Thema abgetrennt habe.
:roll:

[Stevie]

Zitat:

Zitat von Daniel (Beitrag 1213407)

Spannende Frage, die ich mal vom FreePascal-Thema abgetrennt habe.
:roll:

Dann kannste meine Antwort von dort auch bitte hierher verfrachten - danke :)

[schöni]

Aha, danke, dann ist die FRage für mich erst mal beantwortet. Dann ist also Oxygene eine von ObjectPascal verschiedene Sprache mit Pascal Syntax. Begin End statt {} u.a.

[Phoenix]

Zitat:

Zitat von schöni (Beitrag 1213460)

Aha, danke, dann ist die FRage für mich erst mal beantwortet. Dann ist also Oxygene eine von ObjectPascal verschiedene Sprache mit Pascal Syntax. Begin End statt {} u.a.

Äh nein. Oxygene ist Object Pascal mit einigen Spracherweiterungen und Weiterentwicklungen.
Im Gegensatz zu Delphi wurden bei dieser Weiterentwicklung aber alte Zöpfe konsequent abgeschnitten.

[schöni]

Zitat:

Zitat von Phoenix (Beitrag 1213462)

Zitat:

Zitat von schöni (Beitrag 1213460)

Aha, danke, dann ist die FRage für mich erst mal beantwortet. Dann ist also Oxygene eine von ObjectPascal verschiedene Sprache mit Pascal Syntax. Begin End statt {} u.a.

Äh nein. Oxygene ist Object Pascal mit einigen Spracherweiterungen und Weiterentwicklungen.
Im Gegensatz zu Delphi wurden bei dieser Weiterentwicklung aber alte Zöpfe konsequent abgeschnitten.

Was funktioniert somit unter Oxygene im Gegensatz zu ObjectPascal nicht mehr?

[mkinzler]

Oxygene ist ein ObjectPascal-Dialect

[mschaefer]

Wie müsste man vorgehen, wenn man ein VCL-Projekt konvertieren wollte ?

[Phoenix]

Zitat:

Zitat von mschaefer (Beitrag 1213659)

Wie müsste man vorgehen, wenn man ein VCL-Projekt konvertieren wollte ?

Kurze Antwort: Gar nicht / Neu schreiben.

Lange Antwort:
Erstmal die VCL rauswerfen.

Oxygene ist ein Object Pascal Dialekt der etliche Spracherweiterungen (Code Contracts, Aspektorientierte Programmierung, Futures, Inline Interfaces, Duck typing) mit sich bringt.
Der Compiler kommt hat drei unterschiedliche Backends: Einmal .NET/Mono (IL-Code), einmal Java (Java bytecode) und einmal Cocoa (Nativer Mac- / iOS-Assembly-Code).

Da es die VCL nicht für .NET, Java und Cocoa gibt, wirst Du dort kein Land sehen.

Oxygene wurde im übrigen für eine Grundlegend andere Herangehensweise als Delphi entworfen:
Oxygene istausdrücklich NICHT dafür da, einmal Code zu schreiben, für Windows/Linux (.NET/Mono), Mac und iOS zu kompilieren und happy zu sein. Das ist die grundsätzlich falscheste Art von Cross-Platform Entwicklung die man machen kann.

Oxygene ist dafür entworfen, seine Business-Logik einmal zu schreiben, und dann für die jeweilige Plattform, unter Nutzung der dort verfügbaren nativen Controls (z.B. Windows Forms, WPF oder ASP.NET für .NET / Mono, die nativen Mac- bzw. iOS Controls für Cocoa und z.B. SWING für Java) das GUI gezielt für die gewünschte Plattform zu erstellen.

[mschaefer]

Danke! Für beide Varianten :-).

Habe da noch eine Frage: Kann das System C# und Pascal-Code gemischt einsetzen?

[mkinzler]

Zitat:

Zitat von mschaefer (Beitrag 1213716)

Danke! Für beide Varianten :-).

Habe da noch eine Frage: Kann das System C# und Pascal-Code gemischt einsetzen?

Bei Verwendung von Oxygene for .Net ja.

[Phoenix]

Jain. Innerhalb eines einzelnen Projektes: Nein.
Du kannst aber auch nicht C# und VB.NET Files im gleichen Projekt haben.

Innerhalb einer Solution aber ja, problemlos. Du kannst ein Projekt z.B. als Bibliothek in C# schreiben, ein weiteres in VB.NET, eines in F# und eines in Oxygene. Dazu brauchst Du allerdings ein Visual Studio mindestens in der Professional-Edition.

Hast Du das nicht, sondern z.B. nur ein VS-Express Edition für C#, dann klappt das nicht innerhalb der gleichen Solution. Dann kannst Du mit der C# Express deine Bibliothek bauen, und dann das Assembly aus dem Oxygene-Projekt heraus verwenden.

[mschaefer]

Ok, auch dafür erstmal Danke.

Inzwischen liegt hier auch VS-Prof. Wie das mit Delphi weitergeht, da bin ich mir im Moment nicht im klaren.

Für heute war es das :-)

[Furtbichler]

Zitat:

Zitat von Phoenix (Beitrag 1213714)

Oxygene ist dafür entworfen, seine Business-Logik einmal zu schreiben

Jepp, dauert nur länger. Aber ist sauberer.
Delphi ist eben ein RAD-Tool, und imho eines der Besten (für diesen Zweck). Powerbuilder ist noch so ein Kandidat. Aber ist eben gefrickelt. RAD und MVVM/MVC beißt sich nun einmal.

[Phoenix]

Zitat:

Zitat von Furtbichler (Beitrag 1213747)

RAD und MVVM/MVC beißt sich nun einmal.

Ja. Deswegen rante ich ja auch so gegen FMX ;-)

Letzen Endes muss aber jeder selber entscheiden ob er mit RAD schneller am Mark ist, und ihn dann hinterher wegen der fehlenden Anwendungsarchitektur und starken Kopplung im Code die Wartungskosten auffressen, oder ob er etwas länger braucht, dafür aber eine bessere Architektur, automatisiert testbaren Code und deutlich geringere Wartungskosten hat. Zudem lassen sich bei ordentlicher Architektur neue Anforderungen schneller umsetzen bzw. wenn die Architektur doch mal nicht passt, sich diese umbauen und durch Unit- und Integrationstests garantieren, dass der Rest der Anwendung immer noch das tut, was sie soll.
Aber was quatsche ich hier um Binsenweisheiten rum...