Scala (al menos en el JVM) usa type erasure para compatibilidad con Java. feature es widelyheldtosuck. Fixing this would be difficult on the JVM.Genéricos reificados en Scala en .NET/CLR
In contrast to the JVM situation, .NET supports reified generics. ¿Lo usa Scala's .NET implementation? Si no, ¿podría? ¿O qué problemas causaría el uso de la cosificación?
Es un trabajo en progreso, con cuidado para no romper Scal una semántica entre JVM y .NET.
hice esta pregunta en el 2011 en la lista de correo Scala-herramientas y la respuesta viene dada por Miguel García en la que destaca la gran imagen:
Algunas citas:
(1) ¿Qué la vista previa de Scala.Net lo hace actualmente. Como habrás notado, la fase de borrado también se ejecuta como parte de la tubería. Esta es una "característica" de la versión de vista previa, una "característica" que se tuvo que incluir porque la compatibilidad con CLR Generics aún no estaba allí (más sobre este a continuación). Sin embargo, hay una gran ventaja en ejecutar el borrado de estilo JVM en Scala.Net: todos los programas Scala que se basan en ya pueden compilarse en .Net, en lugar de esperar para que CLR Generics esté listo. Los programas que se basan en Java JDK también se pueden compilar, sujeto a la compatibilidad con IKVM de las API de JDK en la pregunta [1].
(2) Soporte para CLR Generics en Scala.Net. La principal motivación para el soporte es que está ganando interoperabilidad con los ensamblajes existentes. En obteniendo esa interoperabilidad, se tendrá cuidado de no romper de la semántica de Scala. En otras palabras, cualquier programa válido de Scala va al para ejecutar y producir los mismos resultados en JVM y .NET. Lo que nos trae al trabajo en progreso [2]. El prototipo inicial maneja solo el subconjunto C# de Scala. Así que ahora me estoy ocupando del resto. Es más trabajo que inicialmente previsto, pero es importante cubrir todo el idioma.
Algunos comentarios más sobre la interoperabilidad con los ensamblados .NET, en problemas nativos particulares. Sí, los conjuntos CLR pueden expresar usando "native int" (diferentes tamaños en diferentes CPU), P/Invoke de funciones C exportadas por un .dll y tal. Scala.Net no tiene como objetivo hacer ese truco de bajo nivel. La interoperabilidad del ensamblado de interés es en el nivel de "Common Language Specification", es decir, lo que normalmente obtiene de cualquier compilador C#, VB.NET, etc. ("normalmente" es decir a menos que se utilicen atributos "[DllImport]" y relacionados C++ - ismos).
Citando de la especificación de la CLI:
--- comenzar la cita --- El Common Language Specification (CLS) - El CLS es un acuerdo entre diseñadores del lenguaje y el marco (es decir, biblioteca de clases) diseñadores . Especifica un subconjunto del CTS (Sistema de tipo común) y un conjunto de convenciones de uso. Los idiomas proporcionan a sus usuarios la mayor capacidad para acceder a los marcos al implementar al menos aquellas partes del CTS que son parte del CLS. De forma similar, los marcos se usarán más ampliamente si sus aspectos exportados públicamente (por ejemplo, clases, interfaces, métodos, y campos) utilizan solo tipos que son parte del CLS y que se adhieren a las convenciones CLS. --- Fin de la cita ---
ver por todo el hilo:
https://groups.google.com/forum/?fromgroups#!topic/scala-tools/JDjstK1_uvM
A partir de la respuesta this question, puede considerar que podría no ser una ventaja tener genéricos conservados en una máquina virtual, porque aún así dictaría qué se puede representar y cuáles son las relaciones entre los tipos. (Para más información, vaya al original blog por Ola Bini).
Otros ejemplos:
Erasure parece útil no sólo para la compatibilidad con versiones anteriores, sino porque el tiempo de ejecución completa la información de tipo promovida por los lenguajes de tipo dinámico tiene un costo. El diseño de .NET CLR Generics aborda este costo por especialización de código. Los casos anteriores deberían haber dejado en claro cuándo se borraron y cuándo se debe culpar al idioma por un defecto en particular.
La red-net es que si la JVM se había materializado genéricos (sin tipo de borrado), no sería posible implementar sistema de tipos de Scala ... sistema de tipos de Scala es más compleja que Java y si la JVM tenía genéricos basados en genéricos de Java, todavía tendríamos problemas en Scala. Por otro lado, la borradura de tipo permite al compilador implementar un sistema de tipo complejo, incluso si toda la información del tipo no está disponible en el tiempo de ejecución.
Por lo que yo sé backend .NET de Scala es muy por detrás de la implementación JVM actual y tampoco admite .NET de los genéricos solo materializó.
Scala 2,10 incluso va más en la dirección de abstraer información de tipo del modelo real de la máquina virtual. Martin Odersky presentó la nueva interacción reflexión/reificación en una presentación que es, por ejemplo, embedded in this entry (comenzando en 42'18 ").
Creo que entonces podrá usar las etiquetas de tipo (que reemplazan los manifiestos) a superar los problemas con el patrón de coincidencia y borrado. Hay un poco en this mailing list thread, pero no sé en qué medida funciona o no.
(pura especulación :) Ir por más abstracción podría ayudar con backends para plataformas que tienen incluso menos información de tipo que la JVM, por ejemplo, una compilación hipotética de JavaScript.
M. Garcia tiene una [artículo] relacionada (http://lampwww.epfl.ch/~ magarcia/ScalaNET/slides/TourCLRGenerics.pdf) y [actualización de estado] (http://lampwww.epfl.ch/~magarcia/ScalaNET/slides/2011-09-06-GenericsGettingCloser.pdf). Pero estos tratan con detalles de implementación; es difícil tener una idea general. –