Zitat von
Phoenix:
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 von
Phoenix:
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 von
Phoenix:
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 von
Phoenix:
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 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.