Posibilidad de tipo de datos lenguaje no asigna a enviado .NET Framework?

Question

¿Alguien sabe de un gestionado lenguaje de programación implementado en .NET que contiene un tipo de datos especializada que no se asigna a través del sistema de tipos común / FCL / BCL o uno que no tenga un enviado equivalente .NET (por ejemplo, enviados tipos estándar como System.String, System.Int32)?

Esta pregunta probablemente vendría de la perspectiva de alguien portar un compilador (aunque no estoy haciendo eso).

¿Es tan simple como la lengua creando un nuevo tipo de datos fuera del BCL / FCL por su tipo especializado? Si lo hace esta interoperabilidad obstaculizar entre los lenguajes de programación que están acostumbrados a la cartografía de lo contrario toda su incorporada en los tipos de datos a lo que hay en el BCL / FCL, como Visual Basic y C #?

puedo imaginar esta situación podría ocurrir si un compilador de lenguaje oscuro de algún tipo es portado a .NET para el que no hay ninguna asignación directa de uno de sus tipos de datos implícitos al Marco enviado.

¿Cómo se apoyó esta situación o se deja en general? ¿Cuál sería la expectativa de que el compilador y el Common Language Runtime?

Answer 1

Delphi para .NET implementado noción del lenguaje Delphi de las variables de clase (que puede contener una referencia a un tipo de clase), los métodos de clases virtuales y constructores virtuales (llamada a través de una referencia de clase). Ninguno de ellos tiene analógica directa en CLR - métodos estáticos en CLR no pueden ser virtuales y constructores no puede ser virtual.

Desde CLR tiene una rica sopa de información de tipo de tiempo de ejecución tal, estos artefactos no son estrictamente necesarias CLR. Si desea construir una instancia de un tipo en tiempo de ejecución de código que no conoce el tipo exacto en tiempo de compilación, se puede hacer eso con la reflexión u otras técnicas. Estas características del lenguaje Delphi surgieron del producto Win32 nativa compilado en tiempo de ejecución información de tipo se limita. Todo esto fue implementado en .NET 1.0 y 1.1, mucho antes que nada a la DLR llegó.

Estas características del lenguaje Delphi podría ser emulado en CLR utilizando la reflexión, pero por razones de rendimiento que optamos por aplicar directamente en la IL mediante la creación de un tipo de "clase meta" que era un coche lateral a cada tipo de clase declarada en Delphi. Si el código de Delphi le asigna un tipo de clase de Delphi a una variable de referencia de clase, generamos código IL para asignar la instancia singleton de la clase meta correspondiente a la variable. llamadas de método virtual a través de la variable de referencia de clase se codegen'd como IL llamadas de método virtual en la instancia de clase meta, que rebotó a la implementación del método estática real en el tipo de clase correspondiente. Esto permitió que las llamadas a métodos virtuales de clase todavía se comportan polimórfica (para llamar a la aplicación apropiada para el tipo de la instancia utilizado para realizar la llamada) y con un costo mínimo en el rendimiento en tiempo de ejecución. Esta aplicación fue de tipo seguro también y verificable.

Estas características método de clase virtuales sólo eran aplicables a clases declaradas en la sintaxis de Delphi, y sólo utilizable en la sintaxis de Delphi. Creo que los tipos meta se han marcado como no compatible con CLS haciendo que otros lenguajes .NET serían (lo más probable) ignorarlos cuando se utiliza clases creadas en Delphi. Otros lenguajes .NET no podían hacer uso de estas características del lenguaje Delphi específico (a menos que el desarrollador fue realmente determinado y se subió a través del andamio para hacer las llamadas apropiadas a / a través de las clases de meta nombrados feos)

En general, no debe esperar otros idiomas a hacer uso de artefactos que no son creadas por CLS / para su idioma. Si desea que otros idiomas para hacer uso de cosas creado por su idioma, tendrá que encontrar la manera de representar su salsa especial de una manera que puede ser representado de una manera razonable en términos compatibles con CLS. Puede que no sea posible en función de la naturaleza de la salsa especial.

métodos de la clase virtual de Delphi estaban disponibles para otros lenguajes .NET como métodos estáticos normales. La naturaleza polimórfica no estaba expuesto a otros lenguajes .NET en gran parte porque CLS (ni otros idiomas) simplemente no pueden expresar la idea.

Lo ideal sería que todos los idiomas sería capaz de expresar cada constructo imaginables igualmente bien. Pero en realidad ese no es el caso. Algunas funciones de representación gráfica son más fáciles de expresar en coordenadas cartesianas, mientras que otros están muy simplificadas mediante el uso de coordenadas polares. Lo mismo es cierto para los lenguajes de programación.

Está bien para inventar nuevos medios de expresión en su propio idioma, incluso cuando se implementa en el CLR. Sólo asegúrese de mantener una definición clara de lo que sus tipos se parecen a los programadores que trabajan fuera de su idioma si espera que el código de su idioma que se llama por otros. Su aplicación tendrá una dualidad:. Cómo se ven las cosas a los usuarios de la lengua, y cómo las cosas se ven a usuarios fuera de su idioma

Nota: No creo que nada de esto se aplica al nuevo producto Delphi para .NET, Delphi Prism. No creo Delphi Prism es compatible con los métodos de clases virtuales.

Answer 2

En realidad no. Cualquier lenguaje tiene la carga última de tener que ser capaz de correr en hardware para tener éxito. El CTS es un modelo muy bueno para los tipos que se pueden manejar de manera eficiente en el hardware actual.

Lo que puede ser necesario es una gran parte del soporte de ejecución de adaptación entre el sistema de tipos del lenguaje y de la CLI. Un ejemplo clásico es el DLR, el sistema de soporte de ejecución para lenguajes dinámicos como Python y Ruby. En esencia, lo que hace un intérprete de lenguaje tan debe hacerlo así, tiene perf comparables. Sin engaños por cierto, todo es puro código C #.

Tal biblioteca de soporte de ejecución de una puede ser lento cuando el lenguaje tiene características que no están disponibles en absoluto. La herencia múltiple, por ejemplo. Se forma nativa 'apoyado' por el CLR y el compilador JIT. Usted puede tomar casi cualquier programa estándar compatible con C ++ que utiliza MI, pasarla por el compilador de C ++ con la opción / clr y usted va a terminar con un conjunto que contiene IL pura que será justo a tiempo compilado en tiempo de ejecución. De ninguna de las maneras podrías llamar el resultado de un programa gestionado, no será verificable y no va a utilizar el recolector de basura. Resolviendo que va a requerir una biblioteca de soporte que va a tener que emular la herencia múltiple. Posible, lo dudo será competitivo.

Answer 3

Bueno, hay c ++ / CLI. No se pueden crear clases de C ++ que no son visibles en .NET. Es eso lo que está buscando?