Thema: Prism Was ist Delphi Prism?

Einzelnen Beitrag anzeigen

Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.640 Beiträge
 
#14

Re: Was ist Delphi Prism?

  Alt 30. Dez 2008, 11:24
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 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 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 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 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.
Sebastian Gingter
Phoenix - 不死鳥, Microsoft MVP, Rettungshundeführer
Über mich: Sebastian Gingter @ Thinktecture Mein Blog: https://gingter.org
  Mit Zitat antworten Zitat