Currying von Typ-Parametern bei generischen Extension-Methoden.
-
Zeus schrieb:
Bald kommt Scala for .Net
Ich habe mal gedacht, dass C++/CLI das Scala in der .NET-Welt werden könnte. War dann nicht ganz so, leider. Ich schreibe jetzt dann meine eigene Sprache, wenn es so weiter geht. C++0x für .NET :trollface:
-
Hallo,
ich verstehe nicht wo du das Problem siehst, bzw. wieso unverständlich ist wieso zweite Variante nicht ohne explizite Typangaben funktioniert.
Als Parameter wird nur der SourceType übergeben, der wäre sogar automatisch ermittelbar, aber TargetType ist unmöglich festzulegen. Der wird nur als Rückgabetyp verwendet und der gehört in praktisch keiner Sprache zur Methodensignatur, kann also nicht verwendet werden. Und auch das Constraint schränkt den Typen ja nicht genug ein, da jede Ableitung von SourceType, bzw. Implementierung wenn es ein Interface wäre, gültig ist. Welchen Typ soll TargetType also haben?
Sprich TargetType ist nicht automatisch ermittelbar, also müssen die Typparameter angegeben werden. Und nur einen von mehreren Typparameter angeben zu müssen geht syntaxtechnisch nicht und das ist auch gut so. Sonsts gäbs wahrscheinlich solchen Code
SuperGenericMethod<,,Typ1,,,,Typ2,Typ3,,>()
-
@Zwergli
Seine meßlatte ist C++. Und es geht sehr wohl, wenn du alle ableitbaren Typeparameter zum Schluss deklarierst, kannst du Sie beim Anwenden auslassen. Das C# nicht kann,... hab ich doch geschrieben. Mussu genauer lesen!
-
Trotzdem fragt er im Post danach doch wieso ein Parameter abgeleitet werden kann, bei zwei aber nicht. Darauf hab ich genauer geantwortet.
Mussu genauer lesen!
Der Vergleich C# und C++ hinkt so oder so - da Generics und Templates haben nicht grundlos unterschiedliche Namen - es sind auch unterschiedliche Dinge.
-
Nagut dann können wir Java nehmen.
-
Wofür?
.Net Generics und Java Generics sind ja technisch wieder zwei ziemlich unterschiedliche Dinge. Die .Net VM kennt Generics, die Java VM nicht. Dort haut der Compiler per Type Erasuere jegliche Generizität raus ausm Code.
-
/rant/ schrieb:
Die Ausdrucksstärke der .NET-Sprachen hat sich nicht so entwickelt, wie ich es mir erhofft hatte
Ich will dir ja nicht zu nahe treten, aber deine letzten paar Threads zum Ausloten was C# kann, die liefen oft in die Richtung: "Aber in C++ geht das!". Wieso nimmst du eigentlich nicht gleich C++? Du versuchst sehr template-lastige Sachen von C++ nach C# zu hieven und das klappt halt nicht wirklich gut.
-
Also bist du mit F# zufrieden?
open System module TestClass = type Box<'a>() = class end;; module TestExtension = open TestClass type Box<'a> with member this.convert<'b when 'b :> System.Object>() = this ;; open TestClass open TestExtension let box = new Box<String>() let result = box.convert<DateTime>()
.method public static class Program/TestClass/Box`1<!!a> Box`1.convert<a,b>(class Program/TestClass/Box`1<!!a> A_0) cil managed ^^^ zwei Type-Parameter { .custom instance void [FSharp.Core]Microsoft.FSharp.Core.CompilationArgumentCountsAttribute::.ctor(int32[]) = ( 01 00 02 00 00 00 01 00 00 00 00 00 00 00 00 00 ) // Code size 3 (0x3) .maxstack 3 IL_0000: nop IL_0001: ldarg.0 IL_0002: ret } // end of method TestExtension::Box`1.convert
-
GPC schrieb:
/rant/ schrieb:
Die Ausdrucksstärke der .NET-Sprachen hat sich nicht so entwickelt, wie ich es mir erhofft hatte
Ich will dir ja nicht zu nahe treten, aber deine letzten paar Threads zum Ausloten was C# kann, die liefen oft in die Richtung: "Aber in C++ geht das!". Wieso nimmst du eigentlich nicht gleich C++? Du versuchst sehr template-lastige Sachen von C++ nach C# zu hieven und das klappt halt nicht wirklich gut.
Du hast schon recht mit deiner Aussage. Schlussendlich geht es um die Frage, was wo machbar ist. C++ kennt kein Reflection.Emit, was zentral ist. C++/CLI ist tot und unterstützt kein WPF. C# hat keine Templates. Aber am Ende des Tages ist wohl C# die einzige Sprache, womit ein hoch dynamisches System noch überhaupt sinnvoll realisierbar ist.
-
/rant/ schrieb:
Aber am Ende des Tages ist wohl C# die einzige Sprache, womit ein hoch dynamisches System noch überhaupt sinnvoll realisierbar ist.
Öh. Wenn das die einzige Anforderung ist, dann geht erstmal viel.
Java, Python, C++ + Lua, C++ + LLVM, ...