Scala Generika im Vergleich zu C#

Question

Ich wundere mich nur über ein Implementierungsdetail von Scala Generika. In C# kann man eine Klasse deklarieren:

class Foo<T1>{} 
class Foo<T1, T2>{} 

in Scala jedoch das gleiche wie

class Foo0[T1]{} 
class Foo1[T1, T2]{} 

Hinweis erklärt werden müssten, wie der Klassenname für mehrere allgemeine Parameter werden gezwungen, geändert. Gibt es einen Grund, dass Scala sich entschieden hat, diese Route zu gehen, anstatt die C# one, die ich für eleganter halte? Ich weiß, das ist wahrscheinlich ein ziemlich kleiner Nitpick, aber ich bin ziemlich neugierig auf die Argumentation.

Answer 1

Ich weiß, Jon Skeet Antwort wurde akzeptiert, aber es ist nicht ganz richtig. Es ist nicht so sehr die JVM, die eine Beschränkung erzwingt, da es die Java-Sprache ist. Scala hat das Entwurfsziel, von Java so einfach wie möglich aufgerufen zu werden, und Java hat kein Konzept, einen Klassennamen basierend auf Typparameter zu überladen. Eine einfache Möglichkeit, das Überladen auf der Basis von Typparametern auf der JVM zu implementieren, wäre beispielsweise die Namensänderung. Dieser Name Mangling müsste jedoch für Java sichtbar sein und wäre hässlich. In Ihrem Beispiel könnte eine hypothetische Scala zwei Klassen kompilieren, Foo_ $ 1 und Foo_ $ 2. Scala könnte das Mangeln unsichtbar machen. Ein Java-Programmierer würde jedoch all diese Hässlichkeit sehen.

Answer 2

Es kann gut teilweise aufgrund der ähnlichen Einschränkungen von Java sein. Wie ich es verstehe, ist Scala meist auf der JVM verwendet, wo Sie generische Typen nicht durch Arity überladen können.

Es sieht aus wie Scala uses type erasure für seine Generika auch im .NET-Port. (Derselbe Artikel erwähnt, dass Scala Generika hatte, lange bevor Java wirklich tat, also selbst wenn Java dies unterstützt, gibt es keine Garantie, dass Scala - sie waren etwas eingeschränkt, als sie zuerst das Feature entwarfen.)

Answer 3

Ich nehme an Es ist für die einfachere Zuordnung zu Java gemacht, die die gleiche Einschränkung hat.

Es wäre möglich gewesen, einige Namensfehler zu machen, aber um den Preis, die Interoperation mit Java zu erschweren. Meiner Meinung nach haben sie die richtige Entscheidung getroffen.