Wie weiter mit Delphi als Sprache

[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 von 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.

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
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