Was ist Delphi Prism?

[QuickAndDirty]

EVTL. Ja, sie können sich aber auch Prism verweigern.

@Threadsteller:
Habe mir Prism mal angeschaut, die IDE ist sehr gut,
die Sprache hat da diverse Vor und Nachteile.

Einige Änderungen was zum beispiel die Deklaration von generics betrifft finde ich gut,
weil ich es besser finde einen Code "lesen" zu können. Andere Dinge sind irgendwie blöd.
Das fängt damit an das der Konstructor nur noch unbezeichnet funktioniert und ich mir
Konstruktoren namens .Create oder .CreateFrom als Klassenmethode bauen muss.

Dann fehlen Destruktoren, finde ich eigentlich ganz praktisch wie es gelöst wurde,
man muss halt ein Muster deklarieren damit bei Zerstörung aufgeräumt wird.

Ja, dann nervt gewaltig das die IDE Formulare nicht darstellen kann wenn eine Klasse
in der Datei mit dem Formular falsch deklariert wurde oder nicht kompilierbar ist, das ist ziemlich
bescheuert .

Die Namenskonventionen der VCL sind nicht mehr da. Das ist wirklich störend. Kein TObject, TForm,...
nur System.bla.pups.Forms.Form oder System.Object
Jetzt müsten die nur noch Casesensitivity einfügen um das Delphieeling komplett zu beseitigen.

Ich würde nichts umbauen. Eher neu schreiben.
Vorteilhaft ist allerdings der Preis.
Ist wohl als eigene Sprache ganz brauchbar, aber alles was man an VCL Wissen hat kann man über Bord werfen.

[mkinzler]

Zitat:

Dann fehlen Destruktoren, finde ich eigentlich ganz praktisch wie es gelöst wurde,
man muss halt ein Muster deklarieren damit bei Zerstörung aufgeräumt wird.

In .Net gibt es nunmal keine Destruktoren ( wg. GC)

[hanspeter]

Zitat:

Zitat von QuickAndDirty

Die Tools können aber nicht InfoPower oder QR oder eigene Komponenten.... oder?

Vergleiche es mit Delphi für PHP. Das einzige was kompatibel ist, ist der Namen.
Prism ist ein lizensiertes Produkt, welches nur wenig mit Delphi zu tun hat.
Das Remobjects-Tool habe ich ausprobiert. Neuschreiben geht schneller. Man scheidert selbst an so kleinen Sachen wie inttostr oder ähnliches.
Viele Konstructe würde man ohnehin anderst lösen, da Prism im Gegensatz zu dem antiken Delphi-Sprachstandard, eine moderne Sprache ist.
Alles was dfm ist,also die gesamte Oberfläche, muss neu gemacht werden.
Oxygene war ein gutes Produkt, welches durch die Codegear-Lizenzpolitik beschädigt wird.
Da Codegear wohl kaum n och ein Neukundengeschäft hat, ist es auf eine schnelle Versionsfolge angewiesen um Umsatz zu generieren.
Mir kommt die Galle hoch, wenn ich in D2009 über IDE-Bugs stolpere, die schon seit D2005 mitgeschleppt werden.
(z.B. Focusierung im Objectinspektor, Syntaxprüfung)
Der wesentliche Vorteil von Prime ist, von Delphi Win32 loszukommen und zu Dot.Net zu wechseln, ohne den gewohnten Sprachraum zu verlassen.


Gruß Peter

[Phoenix]

Zitat:

Zitat von QuickAndDirty

Andere Dinge sind irgendwie blöd.
Das fängt damit an das der Konstructor nur noch unbezeichnet funktioniert und ich mir
Konstruktoren namens .Create oder .CreateFrom als Klassenmethode bauen muss.

Das liegt aber nicht an Prism. Die .NET Runtime erlaubt keine Named Constructoren.
Das geht technisch nicht, da muss sich die Sprache halt mit abfinden.

Zitat:

Zitat von QuickAndDirty

Dann fehlen Destruktoren, finde ich eigentlich ganz praktisch wie es gelöst wurde,
man muss halt ein Muster deklarieren damit bei Zerstörung aufgeräumt wird.

IDisposable. Ja. Auch das hat technische Hintergründe, die im .NET Framework bedingt sind.

Zitat:

Zitat von QuickAndDirty

Ja, dann nervt gewaltig das die IDE Formulare nicht darstellen kann wenn eine Klasse
in der Datei mit dem Formular falsch deklariert wurde oder nicht kompilierbar ist, das ist ziemlich
bescheuert .

Kleiner Tipp: Eine Datei -> Eine Klasse.
Zum Ordnen der Klassen gibt es in .NET Namespaces. Damit kann das angesprochene Problem nicht
auftreten (irgendeine Klasse in der Datei mit dem Formular ist nicht kompilierbar..), und Du hast
einen sauber strukturierten und aufgeräumten Code.

Zitat:

Zitat von QuickAndDirty

Die Namenskonventionen der VCL sind nicht mehr da. Das ist wirklich störend. Kein TObject, TForm,...
nur System.bla.pups.Forms.Form oder System.Object
Jetzt müsten die nur noch Casesensitivity einfügen um das Delphieeling komplett zu beseitigen.

Das ist nicht störend sondern einfach nur ungewohnt. ;-)
Und Du kannst Dir wenn Du magst einen alias TObject = System.Object und TForm = System.Windows.Forms.Form anlegen and there you go.

Und Case-Sensitivity ist auch zum Teil Beseitigt. Das liegt aber auch an .NET. C# ist nunmal Case Sensitive und wenn Du in C# deklarierte Assemblies anziehst und sich da Klassen im gleichen Namespace nur im Casing unterscheiden musst Du das auch irgendwie verwenden können. Die Klasse 'Test' ist halt eine andere als 'TEST'. Demnach würde myTest := new Test() und MyTest2 := new TEST auch jeweils ein anderes Objekt liefern. Wenn Du nun MyTest := new test(); schreibst, bekommst Du dann eine Instanz von Test oder TEST? Das sind nunmal Dinge, die dem .NET Framework geschuldet sind.

Zitat:

Zitat von QuickAndDirty

Ich würde nichts umbauen. Eher neu schreiben.
Vorteilhaft ist allerdings der Preis.
Ist wohl als eigene Sprache ganz brauchbar, aber alles was man an VCL Wissen hat kann man über Bord werfen.

Das alte Wissen kann man immer noch ganz gut weiterverwenden. Zumindest im Windows Forms Bereich. Die FCL ist nunmal auch von Anders Hejlsberg designed wie auch die VCL damals, und das sieht man ihr an. Und ob das Ding nun Caption oder Text heisst ist nur ein kleiner Umstellungsaufwand, als Delphianer wissen wir wenigstens, wo wir nach Properties und Events suchen müssen.

Prism (Oxygene) ist von Anfang an als .NET Sprache entwickelt worden, und die Jungs bei RemObjects mussten sich (zum Glück) niemals mit Rückwärtskompatibilät zu Win32 und der VCL rumschlagen. Das heisst Dinge, die schon von der Plattform her unterschiedlich zu Delphi sind (eben keine Named Constructors, keine Destructoren, Case-Sensitivity bei konsumierten Typen mit unterschiedlichem Casing) sind halt auf eine saubere und .NET-Like Art gelöst worden.

Und man hat gegenüber C# einfach den Vorteil, dass es so Dinge wie Async, Futures und z.B. das notify - Keyword hat.

[QuickAndDirty]

Zitat:

Zitat von Phoenix

Zitat:

Zitat von QuickAndDirty

Andere Dinge sind irgendwie blöd.
Das fängt damit an das der Konstructor nur noch unbezeichnet funktioniert und ich mir
Konstruktoren namens .Create oder .CreateFrom als Klassenmethode bauen muss.

Das liegt aber nicht an Prism. Die .NET Runtime erlaubt keine Named Constructoren.
Das geht technisch nicht, da muss sich die Sprache halt mit abfinden.

Nö, ich habe ja nen Workarraund über Klassenmethoden. Wäre nur schön wenn das automatisierbar
einzufügen ginge.

Zitat:

Zitat von Phoenix

Zitat:

Zitat von QuickAndDirty

Ja, dann nervt gewaltig das die IDE Formulare nicht darstellen kann wenn eine Klasse
in der Datei mit dem Formular falsch deklariert wurde oder nicht kompilierbar ist, das ist ziemlich
bescheuert .

Kleiner Tipp: Eine Datei -> Eine Klasse.
Zum Ordnen der Klassen gibt es in .NET Namespaces. Damit kann das angesprochene Problem nicht
auftreten (irgendeine Klasse in der Datei mit dem Formular ist nicht kompilierbar..), und Du hast
einen sauber strukturierten und aufgeräumten Code.

Ja, das wäre ein Workaround, eine Lösung ist das nicht.

Zitat:

Zitat von Phoenix

Zitat:

Zitat von QuickAndDirty

Die Namenskonventionen der VCL sind nicht mehr da. Das ist wirklich störend. Kein TObject, TForm,...
nur System.bla.pups.Forms.Form oder System.Object
Jetzt müsten die nur noch Casesensitivity einfügen um das Delphieeling komplett zu beseitigen.

Das ist nicht störend sondern einfach nur ungewohnt. ;-)
Und Du kannst Dir wenn Du magst einen alias TObject = System.Object und TForm = System.Windows.Forms.Form anlegen and there you go.

Nein das stört wenn ich nicht am Klang erkenne ob es eine Typ oder eine Variable ist. Vor allem daher da sie so verwandte namen haben. Das mit dem Aliasing wäre gut wenn es eine vorgefertigte Aliasing Libs gäbe die ich einbinden könnte und gut.

Zitat:

Zitat von Phoenix

Zitat:

Zitat von QuickAndDirty

Ich würde nichts umbauen. Eher neu schreiben.
Vorteilhaft ist allerdings der Preis.
Ist wohl als eigene Sprache ganz brauchbar, aber alles was man an VCL Wissen hat kann man über Bord werfen.

Das alte Wissen kann man immer noch ganz gut weiterverwenden. Zumindest im Windows Forms Bereich. Die FCL ist nunmal auch von Anders Hejlsberg designed wie auch die VCL damals, und das sieht man ihr an. Und ob das Ding nun Caption oder Text heisst ist nur ein kleiner Umstellungsaufwand, als Delphianer wissen wir wenigstens, wo wir nach Properties und Events suchen müssen.

Was ist mit der Presentation Foundation ? Warum FCL und WPF?

Zitat:

Zitat von Phoenix

Und man hat gegenüber C# einfach den Vorteil, dass es so Dinge wie Async, Futures und z.B. das notify - Keyword hat.

So dinge Wie parallel fand ich auch gleich ziemlich geil.
Wenn es wirklich so ist das ich quasi Multithreading in der Sprache mit eingebaut habe und mich nicht zwingend mit Thread Objekten abgeben muss wenn ich vorher schon weiß wie viele und welche Vorgänge parallel laufen sollen.

Problem ist halt das sich Prism nur für neue Anwendungen lohnt. Und da es Geld kostet, sich nicht zum lernen eignet.
Das das in unserer Firma nicht eingesetzt wird ist so gut wie sicher, da Codegear schon soviele non VCL Produkte sterben lassen hat, traut der Chef sich sicher nicht zu irgendetwas non VCL-mässiges von Codegear einzusetzen. Zumal unsere VCL Anwendungen ja auch gepflegt werden müssen.
Gäbe es sowas wie TurboOxygeneExplorer hätte das Produkt ne Chance das man sich privat mal länger damit beschäftigt.

[mkinzler]

Zumindest eine Frei CLI-Version gibt es ja

[Phoenix]

Zitat:

Zitat von QuickAndDirty

Das mit dem Aliasing wäre gut wenn es eine vorgefertigte Aliasing Libs gäbe die ich einbinden könnte und gut.

Ich habe mir ShineOn nicht wirklich intensiv angeschaut, aber ich kann mir gut vorstellen, dass bei ShineOn genau sowas drin ist.

Zitat:

Zitat von QuickAndDirty

Was ist mit der Presentation Foundation ? Warum FCL und WPF?

Das Konzept der WPF ist nicht so straight forward (bzw. Delphi-like) wie das der FCL.
Was ich sagen wollte war, dass der Umstellungsaufwand von Delphi VCL auf .NET Windows Forms relativ gering ist, weil die Grundkonzepte exakt identisch sind, und es eben im großen und ganzen nur auf andere Typen und andere Namen hinausläuft, und das ganze um ein sauberes Databinding erweitert.

Hinter der WPF liegt ein komplett anderes Konzept (XAML), hier würde man für effizientes Arbeiten auch andere Patterns nutzen (MVVM anstelle von MVC). Auch so Dinge wie Animationen in WPF und das Event-Bubbling sind Konzepte, die sich so stark von der VCL und auch Windows Forms unterscheiden, dass Du, egal von woher Du kommst, einen entsprechenden Einarbeitungsaufwand hast.

Zitat:

Zitat von QuickAndDirty

So dinge Wie parallel fand ich auch gleich ziemlich geil.
Wenn es wirklich so ist das ich quasi Multithreading in der Sprache mit eingebaut habe und mich nicht zwingend mit Thread Objekten abgeben muss wenn ich vorher schon weiß wie viele und welche Vorgänge parallel laufen sollen.

Genau so ist es ;-)

Zitat:

Zitat von QuickAndDirty

Das das in unserer Firma nicht eingesetzt wird ist so gut wie sicher, da Codegear schon soviele non VCL Produkte sterben lassen hat, traut der Chef sich sicher nicht zu irgendetwas non VCL-mässiges von Codegear einzusetzen. Zumal unsere VCL Anwendungen ja auch gepflegt werden müssen.
Gäbe es sowas wie TurboOxygeneExplorer hätte das Produkt ne Chance das man sich privat mal länger damit beschäftigt.

Mein Rede *seufz*

Aber die Sache mit Non-VCL Produkte von Borland / CodeGear kann ich so nicht stehen lassen:
Embarcadero CodeGear hat Prism lediglich als Oxygene von RemObjects lizenziert und um eigene Pakete wie DataSnap und DbExpress erweitert. Die Rechte an Oxygene, sowie die Weiterentwicklung verbleiben bei RemObjects.

Sollte sich CodeGear dazu entscheiden, 'Delphi Prism' als Produkt fallen zu lassen, so ändert sich nicht. RemObjects wird wieder Oxygene anbieten (dann halt ohne DataSnap und DbExpress) und das Produkt stirbt einem nicht unter den Füßen weg. Zudem hat RO schon öfter gesagt, dass Oxygene nicht sterben wird. Sollte es dennoch tatsächlich irgendwann dazu kommen, dann soll das Produkt OpenSourced werden, damit es die Community und die aktiven User weiterpflegen können.

Will heissen: Solange man sich nicht auf DbExpress und DataSnap stützt (sorry, aber warum DbExpress wenn ich ADO.NET habe? Und wer nutzt schon Midas / DataSnap in .NET ? ), ist man auf jeden Fall auf der sicheren Seite.

[QuickAndDirty]

Tja wir stellen seit über 2 Jahren ein extrem Großes Projekt von BDE auf
DBEXPRESS um. Leider haben wir echt alles genutzt was man an Oberflächen und Datenbankverzahnung
so fabrizieren kann...(Vor meiner Zeit...NO COMMENT)
Wenn das Risiko besteht das DBExpress aus Prism wegbricht ist das quasi der Tod.

[QuickAndDirty]

Zitat:

Zitat von mkinzler

Zumindest eine Frei CLI-Version gibt es ja

Was bedeutet CLI-Version?
Wenn es gut ist: Wo gibts die?

[sx2008]

Wie ist denn die Geschwindigkeit des Delphi Prism Compilers?
Ist das mit Delphi 7 vergleichbar?