Delphi Prism XE

[Stevie]

Zitat:

Zitat von Phoenix (Beitrag 1107829)

So, seit heute gibt es auch mehr Infos über neue Sachen, die in XE2 kommen werden (und die es in C# auch nicht gibt ;-) ): http://blogs.remobjects.com/blogs/mh/2011/06/22/p2607

"Fix it" is ma geil! 8-)

[divBy0]

Gibts dann eigentlich auch eine IDE für Mac OS?

[implementation]

Zitat:

Zitat von Phoenix (Beitrag 1107810)

Zitat:

Zitat von implementation (Beitrag 1107794)

Also ein Grund für mich Prism C# vorzuziehen wäre allein schon die Tatsache, dass Prism Typen gleichsetzen kann ..

Auch wenn ich Dich jetzt enttäusche, aber das ist ein Standard-Feature der CLR und auch in C# verfügbar:

Code:

using MySecondTypeName = MyNameSpace.SomeSubNamespace.SomeType;

Das ganze ist beim using - Keyword dokumentiert.

Nöööö, das kenne ich.
Aber es ist nur ein lokaler Alias.
Binde ich jetzt diese Assembly irgendwo anders ein, wird MySecondTypeName dort unbekannt sein. :wink:

[Phoenix]

Zitat:

Zitat von divBy0 (Beitrag 1107835)

Gibts dann eigentlich auch eine IDE für Mac OS?

Die ist schon seit über einem Jahr bei Delphi Prism XE dabei. Siehe z.B. diesen Blog-Post mit Video hier: http://blogs.remobjects.com/blogs/se...ng/2010/03/29/

[Phoenix]

Und seit heute sind auch die Enten offiziell ;-)

[FredlFesl]

Fördert dieses 'duck' nicht schlampige Programmierung? Nach dem Motto: "Ich bin zu faul, es richtig zu machen und nun gibt es auch eine Programmiersprache, die Faulheit unterstützt".

[Stevie]

Wie viele andere Language Features muss man auch Duck Typing mit Verstand einsetzen.
Das Beispiel mit dem ToString macht das sehr schön deutlich. Es wird definiert, dass man diese Methode in dem übergebenen Parameter braucht.
Natürlich könnte man dieses Interface auch herkömmlich implementieren und für jedes Objekt eine eigene Klasse bauen, ist aber enorm umständlich und nicht unbedingt praktikabel.

[FredlFesl]

Ah. Aber wenn irgend jemand später mal die Methode umbenennt oder verändert, klappt das mit dem duck-Zeugs nicht mehr. Ich halte das so ebenso elegant wie typecasting, denn eigentlich ist es ja nix anderes.

Und natürlich muss man alles mit Verstand einsetzen, aber nach der Logik wäre selbst C eine tolle Programmiersprache.

[Phoenix]

Zitat:

Zitat von FredlFesl (Beitrag 1109804)

Fördert dieses 'duck' nicht schlampige Programmierung? Nach dem Motto: "Ich bin zu faul, es richtig zu machen und nun gibt es auch eine Programmiersprache, die Faulheit unterstützt".

Nein. Das ist inbesondere dann wichtig, wenn man es in bestimmten Situationen gerne richtig machen würde, es aber nicht kann weil z.B. zugekaufte Klassen sealed sind oder ein Interface implementieren würden ohne es zu deklarieren.

Auch bietet sich z.B. Ducktyping an, wenn man die Nutzung fremder Bibliotheken testen will und diese z.B. keine Interfaces definieren. Konkret:
Ich definiere mir selber ein Interface das genau so aussieht wie die fremde Komponente, und nutze diese Komponente dann mit dem eigenen Interface mittels Ducktyping. Nun habe ich meinen Code zum einen von der fremden Komponente entkoppelt. Ich habe also eine konkrete Abhängigkeit weniger, was per se mal nicht schlecht ist. Zum anderen habe ich nun eine einfache Möglichkeit die Komponente zu mocken wenn ich meinen Code mit Unit-Tests abdecken will.

Die eigentliche Idee hinter Ducktyping in Prism ist aber folgende:
Ich will Code für .NET und Java schreiben. Nun definiere ich mir Interfaces gegen EINE der beiden Seiten. z.B. gegen System.IO.Stream in der .NET Welt. Nun kann ich diesen mittels Ducktyping direkt verwenden. Auf der Java-Seite wrappe ich nun das Java-Stream Objekt so, dass es mein Interface erfüllt. Oder andersrum. Auf jeden Fall spare ich mir auf einer der beiden Plattformen das wrappen, und das mit einer sauberen Lösung, da Typsicher.

[FredlFesl]

Wie jedes gute Werkzeug: In den falschen Händen ist es nicht zu gebrauchen. In den richtigen Händen jedoch ziemlich mächtig.

Ich habe verstanden. :)