¿Es posible que .NET CLR admita Objective-C? ¿Hay alguna razón (ya sea desde un punto de vista legal o de implementación) por qué esto no sería posible?¿Qué se necesita para agregar soporte de Objective-C al tiempo de ejecución de lenguaje común de .NET?
En el espíritu del desarrollo de aplicaciones multiplataforma, sería bueno poder escribir y ejecutar aplicaciones Objective-c en máquinas con Windows. Al menos creo que lo haría.
No, realmente no hay. .NET compila a IL (o CIL o MSIL), que es básicamente código de máquina para una máquina virtual. Puede programar en IL como lo hace en ensamblaje (no es que haya visto a nadie hacerlo). Si tuviera la experiencia, el conocimiento y la orientación, no habría ningún problema al escribir un compilador Objective-C to IL. Demonios, incluso hay functional programming languages (F#) para .NET. Además de las capacidades de mensajería y las bibliotecas, no es muy diferente de C#, VB.NET, etc.
¡Qué gran idea! Objective-C# o algo así.
Aquí es donde puede empezar: Wikiepedia on Microsoft's IL.
Objective-C es un superconjunto estricto de C. Como tal, tiene un montón de características como punteros que se traducen mal en .NET. Por supuesto, puede ser que, en la práctica, la mayoría de los programas de Objective-C estén escritos de tal manera que también compilarían contra una versión más estrechamente definida de la especificación del lenguaje que era más restrictiva pero que podría traducirse en seguridad. código.
Suponiendo que este sea el caso, la parte de envío del método de Objective-C es un ajuste natural para las capacidades dinámicas del DLR. De hecho, he considerado crear un puerto así.
No debería haber problemas para alojar el objetivo C en la cima del CLR. Probablemente pueda implementar el tiempo de ejecución ontop del DLR o, en el peor de los casos, implemente el suyo. Eso todavía es significativamente diferente de compilar cualquier base sustancial de código Objective C para el CLR, ya que la gran mayoría del código del Objetivo C que probablemente le interese depende de los marcos de trabajo de Apple.
Al final, o bien deberá volver a implementarlos, o bien, pasar el objetivo C a los marcos .NET, lo que le permitiría escribir el código Objective C, pero no usaría un marco compatible con cualquier Objective C existente código. Es posible que desee echar un vistazo a Cocotron que es un entorno de compilación cruzada que permite a los desarrolladores de Mac mover algunas aplicaciones de Objective C a Windows. Eso debería proporcionar un ejemplo razonablemente bueno de un tiempo de ejecución de Objective C para Windows, así como proporcionar potencialmente algunos marcos necesarios para hacer que una cantidad razonable de código de Objective C se pueda utilizar una vez que aparezca un compilador que pueda .NET
If te refieres a poder escribir aplicaciones .NET usando la sintaxis de Objective-C y poder usar las estructuras de datos de los marcos de Foundation (como NSArray) esto es trivial (aunque largo) para lograr. No sería diferente a agregar soporte para cualquier idioma.
Sin embargo lo que hace que el desarrollo de Objective-C muy bien en el Mac no es la sintaxis, que es la del otro API que Apple ofrece como:
Además de estas API lo cual sería mucho más difícil de implementar, también tiene que pensar en cosas como Bindings support y Key Value Observing que serían mucho más difíciles de implementar en el CLR.
con respecto al último párrafo, es de esperar que sea un envoltorio similar al Cocoa sobre el sistema de enlace de datos de WPF e INotifyPropertyChanged. – Jimmy
Como han dicho otros, sí, es posible. Si es una buena idea (especialmente "en el espíritu del desarrollo multiplataforma") es otra cuestión. Una vez más, como se ha observado, el lenguaje no es mucho sin sus bibliotecas. Dado que Objective C ahora se usa casi exclusivamente dentro de un contexto Mac/iPhone, poder escribir código en Windows no te va a comprar mucho si son tus objetivos.
Además, puede escribir Objective C en Windows ya - Creo que gcc, que normalmente se usa con XCode, compilará Obj C en Windows también, así como GnuStep.
¿Qué simplemente deja si hay una ventaja de ejecutar Objective C sobre .Net? Hay son algunas características agradables de Objective C que no se encuentran en sus lenguajes .Net típicos. Personalmente, me gusta mucho el etiquetado del nombre del método de los parámetros. Sin embargo, no creo que sea suficiente para que valga la pena hacerlo. La mayoría de las cosas en las que Objective C es bueno, C# tiene sus propias soluciones. Ahora, si tan solo se frenan al negarse a implementar los argumentos nombrados ...
Usando NObjective bridge puede trabajar con las clases existentes de Objective-C en C# o crear nuevas. También después del lanzamiento final de 'Visual Studio 2010' y '.NET 4' agregaré soporte DLR para NObjective.
¿Ya está hecho? :) – bzlm
¿Qué pasa con Objective-J y Cappuccino para .Net, en lugar de Objective-C y Cocoa? Objective-J es tan atractivo como ObjC, sin embargo, ObjJ está más cerca de C# que ObjC (sin punteros, gc, etc.)
Hace poco pregunté sobre esto en el foro de desarrolladores de Cappuccino, y me apuntaron hacia Jurassic (un compilador de Javascript para .Net). También dijeron que Cappuccino funciona bien en IronJS. Entonces, parece que los componentes están ahí (ObjJ -> Javascript -> .Net), pero el puente que los une tiene que ser construido.
¿Alguien más ve algún valor en esto?
¿Se puede compilar C++ en .NET bytecode? Si es así, debería ser posible escribir un compilador de Objective-C para .NET. (Aunque no estoy demasiado familiarizado con .NET, creo que puede compilar C++ para .NET, ¿pero realmente se compila para el bytecode de .NET o hace otra cosa?) – mipadi
No, no se puede compilar C++ arbitrario a IL, aunque puede ser un subconjunto extraño de esto. Esa es la fuente de mi comentario. :) –
Derecha - una de las características clave del código .net "seguro" es la falta de soporte para los punteros (obtenemos referencias en su lugar) y, en particular, la aritmética del puntero. Objective-C es un superconjunto de C, lo que significa que es compatible con la aritmética del puntero y, como tal, cualquier aplicación que use esa característica de idioma será casi imposible de convertir a código CLR administrado. – Dathan