sistema - ¿Qué se necesita para agregar el soporte de Objective-C al tiempo de ejecución de lenguaje común de.NET?
swift versions (7)
Como otros han dicho, 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 señalado, 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, ya puedes escribir Objective C en Windows: creo que gcc, que normalmente se usa con XCode, también compilará Obj C en Windows, así como GnuStep.
¿Qué simplemente deja si hay una ventaja para ejecutar Objective C sobre .Net? Hay algunas características interesantes 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 fuesen al negarse a implementar argumentos nombrados ...
¿Es posible que .NET CLR sea compatible con 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?
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 debería haber problemas para alojar Objective C ontop 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, necesitará volver a implementarlos, o unir el objetivo C a los marcos de .NET, lo que le permitiría escribir el código de Objective C, pero no usaría un marco compatible con ningún código Objective C existente. 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 orientar a .NET.
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 lenguajes de programación funcionales (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 puedes comenzar: Wikiepedia en IL de Microsoft.
Objective-C es un superconjunto estricto de C. Como tal, tiene muchas 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.
Asumiendo que este es el caso, la parte de envío de métodos de Objective-C es un ajuste natural para las capacidades dinámicas del DLR . De hecho, he considerado crear un puerto así.
Si te refieres a poder escribir aplicaciones .NET usando la sintaxis de Objective-C y poder usar las estructuras de datos de los frameworks 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 sea genial en la Mac no es la sintaxis, sino las otras API que proporciona Apple como:
Además de estas API que serían mucho más difíciles de implementar, también tienes que pensar en cosas como el soporte de Bindings y Key Value Observing, que sería mucho más difícil de implementar en el CLR.
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.
¿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 señalaron 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?