Возможно ли, что .NET CLR поддерживает Objective-C? Существуют ли какие-либо причины (с правовой или реалистичной), почему это невозможно?
В духе кросс-платформенной разработки приложений было бы неплохо иметь возможность писать и запускать приложения Objective-c на машинах Windows. По крайней мере, я думаю, что это будет.
Objective-C является строгим надмножеством C. Как таковой, он получил множество функций, таких как указатели, которые плохо переводятся на .NET. Конечно, может быть, что на практике большинство программ Objective-C написаны таким образом, что они также будут компилироваться против более строго определенной версии спецификации языка, которая была бы более ограничительной, но могла бы быть переведена в безопасную код.
Предполагая, что это так, часть отправки метода Objective-C является естественным подходом для динамических возможностей DLR. Я действительно думал о создании такого порта.
Не должно быть проблем с хостингом Objective C ontop CLR. Вы, вероятно, можете реализовать runtime ontop 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.
Если вы имеете в виду возможность писать .NET-приложения с использованием синтаксиса Objective-C и возможность использовать структуры данных из фреймворков Foundation (например, NSArray), это тривиально (хотя и длительное). Это ничем не отличается от добавления поддержки для любого языка.
Однако то, что делает разработку Objective-C отличной на Mac, не является синтаксисом, это другой API, который Apple предоставляет, например:
В дополнение к этим API, которые было бы намного сложнее реализовать, вам также нужно подумать о таких вещах, как Bindings поддержка и Key Value Observing, который будет намного сложнее реализовать в среде CLR.
Нет, на самом деле нет..NET компилируется в IL (или CIL или MSIL), который является главным образом машинным кодом для виртуальной машины. Вы можете программировать в IL, как в сборке (не то, что я видел, как кто-то это делает). Если бы у вас был опыт, знания и соображения, не было бы проблем писать компилятор Objective-C для IL. Черт, есть даже языки функционального программирования (F #) для .NET. Помимо возможностей обмена сообщениями и библиотек, он не слишком отличается от С#, VB.NET и т.д.
Какая удивительная идея! Objective-C # или некоторые такие.
Здесь вы можете начать: Wikiepedia на Microsoft IL.
Как говорили другие, да, возможно. Является ли это хорошей идеей (особенно в духе кросс-платформенного развития), является другим вопросом. Опять же, как уже отмечалось, язык не сильно отличается от его библиотек. Поскольку Objective C теперь используется почти исключительно в контексте Mac/iPhone, возможность писать код в нем на Windows не собирается покупать вас много, если они являются вашими целями.
Кроме того, вы можете писать Objective C на Windows уже - я считаю, что gcc, который обычно используется с XCode, будет компилировать Obj C на Windows тоже, а также GnuStep.
Что просто выходит, есть ли преимущество для запуска Objective C поверх .Net? Есть некоторые интересные функции Objective C, которые не найдены на ваших типичных языках .Net. Лично мне очень нравится обозначение параметров имени метода. Однако я не думаю, что это достаточно, чтобы сделать все возможное, чтобы это осуществить. Большинство вещей, на которые нацелен Objective C, у С# есть собственные решения. Теперь, если бы они отказались от реализации именованных аргументов...
Используя NObjective bridge, вы можете работать с существующими классами Objective-C на С# или создавать новые. Также после финальной версии "Visual Studio 2010" и ".NET 4" я добавлю поддержку DLR для NObjective.
Как насчет Objective-J и Cappuccino для .Net, а не Objective-C и Cocoa? Objective-J столь же привлекателен, как ObjC, однако ObjJ ближе к С#, чем ObjC (без указателей, gc и т.д.)
Недавно я спросил об этом на форуме разработчиков Cappuccino, и они указали мне на Jurassic (компилятор Javascript для .Net). Они также сказали, что Cappuccino отлично работает на IronJS. Итак, похоже, что компоненты есть (ObjJ → Javascript → .Net), но мост, соединяющий их вместе, должен быть построен.
Кто-нибудь еще видит в этом значение?