Genéricos de Scala en comparación con C#

Question

Me pregunto acerca de un detalle de implementación de los genéricos de Scala. En C# se puede declarar una clase como:

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

en Scala sin embargo, el mismo que tendría que ser declarado como

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

Aviso cómo el nombre de la clase se ve obligado a cambiar para múltiples parámetros genéricos. ¿Hay alguna razón por la cual Scala decidió ir por esta ruta en lugar de la C# que creo que es más elegante? Sé que este es probablemente un pequeño detalle, pero tengo bastante curiosidad sobre el razonamiento.

Answer 1

Sé que la respuesta de Jon Skeet ha sido aceptada, pero no está del todo bien. No es tanto la JVM lo que fuerza una limitación, ya que es el lenguaje Java. Scala tiene el objetivo de ser tan fácilmente llamable desde Java como sea posible y Java no tiene el concepto de sobrecargar un nombre de clase basado en el parámetro de tipo arity. Por ejemplo, una forma simple de implementar la sobrecarga en función de los parámetros de tipo en la JVM sería con el cambio de nombre. Sin embargo, ese cambio de nombre debería ser visible para Java y sería feo. En su ejemplo, un hipotético Scala podría compilar dos clases, Foo_ $ 1 y Foo_ $ 2. Scala podría hacer ese mangle invisible. Sin embargo, un programador de Java vería toda esa fealdad.

Answer 2

Puede deberse en parte a las restricciones similares de Java. Según tengo entendido, Scala es principalmente utilizado en la JVM, donde no se pueden sobrecargar los tipos genéricos por arity.

Parece que Scala uses type erasure también es genérico, incluso en el puerto .NET. (El mismo artículo menciona que Scala tuvo genéricos mucho antes de Java realmente lo hizo, por lo que incluso si Java hizo apoyo de esto, no hay ninguna garantía de que Scala sería -. Que se limita un poco la primera vez que diseñaron la función)

Answer 3

supongo se hace para mapear más fácilmente a Java, que tiene la misma restricción.

Habría sido posible cambiar el nombre, pero a costa de dificultar la interoperación con Java. En mi opinión, tomaron la decisión correcta.