Что потребуется, чтобы добавить поддержку Objective-C к общеязыковой среде выполнения .NET?

Question

Возможно ли .NET CLR для поддержки Objective-C? Есть ли какие-либо причины (с юридической или практической точки зрения), почему это было бы невозможно?

В духе кроссплатформенной разработки приложений было бы неплохо иметь возможность писать и запускать приложения Objective-c на компьютерах с Windows. По крайней мере, я так думаю.

Answer 1

Objective-C является строгим надмножеством языка C. Как таковой, он обладает множеством функций, таких как указатели, которые плохо транслируются на .NET. Конечно, может случиться так, что - на практике - большинство программ Objective-C написаны таким образом, что они также будут компилироваться с более жестко определенной версией языковой спецификации, которая была более строгой, но могла быть переведена в безопасную код.

Предполагая, что это так, часть диспетчеризации метода Objective-C является естественным соответствием динамическим возможностям DLR . Я действительно подумывал о создании такого порта.

Answer 2

Не должно быть проблем с размещением Objective C поверх CLR. Вероятно, вы можете реализовать время выполнения DLR, или, в худшем случае, реализовать свой собственный. Это по-прежнему существенно отличается от компиляции любых существенных основ кодов Objective C для CLR, поскольку подавляющее большинство кода Objective C, который вас может заинтересовать, зависит от сред Apple.

В конце концов вам потребуется либо переопределить их, либо соединить Objective C с платформой .NET, что позволит вам писать код Objective C, но при этом не будет использоваться инфраструктура, совместимая с любым существующим кодом Objective C , Возможно, вы захотите взглянуть на Cocotron - среду кросс-компиляции, которая позволяет разработчикам Mac переносить некоторые приложения Objective C в Windows. Это должно обеспечить достаточно хороший пример времени выполнения Objective C для Windows, а также потенциально предоставить несколько платформ, необходимых для того, чтобы сделать разумное количество кода Objective C пригодным для использования после запуска компилятора, который может быть нацелен на .NET

Answer 3

Если вы имеете в виду возможность написания приложений .NET с использованием синтаксиса Objective-C и возможность использовать структуры данных из каркасов Foundation (таких как NSArray), это тривиально (хотя и долго). Это ничем не отличается от добавления поддержки любого языка.

Однако то, что делает разработку Objective-C великолепной на Mac, заключается не в синтаксисе, а в другом API, который предоставляет Apple:

• Основные данные
• Core Audio
• Кварцевый
• Базовая анимация

В дополнение к этим API, которые было бы намного сложнее реализовать, вы также должны подумать о таких вещах, как Bindings support и Key Value Observing , которые было бы намного сложнее реализовать в CLR.

Answer 4

Используя NObjective bridge, вы можете работать с существующими классами Objective-C в C # или создавать новые. Также после окончательного выпуска Visual Studio 2010 и .NET 4 я добавлю поддержку DLR для NObjective.

Answer 5

Как уже говорили другие, да, это возможно. Является ли это хорошей идеей (особенно «в духе кроссплатформенной разработки») - это другой вопрос. Опять же, как уже отмечалось, язык не так уж много без своих библиотек. Поскольку Objective C теперь используется почти исключительно в контексте Mac / iPhone, возможность писать в нем код в Windows не принесет вам большой пользы, если они будут вашими целями.

Кроме того, вы уже можете написать Objective C для Windows - я полагаю, что gcc, который обычно используется с XCode, будет компилятором Obj C для Windows также, как и GnuStep.

Что оставляет преимущество в использовании Objective C над .Net? - это некоторые приятные особенности Objective C, которых нет в ваших типичных языках .Net. Лично мне очень нравится маркировка имени метода параметров. Однако я не думаю, что этого достаточно, чтобы это стоило того, чтобы его перенести. Большинство вещей, с которыми хорошо справляется Objective C, C # имеет свои собственные решения. Если бы только они отказались от реализации именованных аргументов ...

Answer 6

Нет, там действительно нет. .NET компилируется в IL (или CIL или MSIL), который в основном является машинным кодом для виртуальной машины. Вы можете программировать на IL так же, как на ассемблере (не то чтобы я видел, чтобы кто-то делал это). Если бы у вас был опыт, знания и мысли, не было бы проблем с написанием компилятора Objective-C для IL. Черт, есть даже функциональные языки программирования (F #) для .NET. Помимо возможностей обмена сообщениями и библиотек, он не слишком отличается от C #, VB.NET и т. Д.

Какая классная идея! Objective-C # или что-то подобное.

Вот с чего вы могли бы начать: Википедия по Microsoft's IL.

Answer 7

А как насчет Objective-J и капучино для .Net, а не Objective-C и какао? Objective-J так же привлекателен, как ObjC, однако ObjJ ближе к C #, чем ObjC (без указателей, gc и т. Д.)

Недавно я спросил об этом на форуме разработчиков Cappuccino, и они указали мне на Jurassic (компилятор Javascript для .Net). Они также сказали, что Cappuccino отлично работает на IronJS. Итак, похоже, что компоненты есть (ObjJ -> Javascript -> .Net), но мост, связывающий их вместе, должен быть построен.

Кто-нибудь еще видит какое-либо значение в этом?