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

Ответ 1

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

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

Ответ 2

Не должно быть проблем с хостингом 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.

Ответ 3

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

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

• Основные данные
• Core Audio
• Quartz
• Основная анимация

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

Ответ 4

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

Какая удивительная идея! Objective-C # или некоторые такие.

Здесь вы можете начать: Wikiepedia на Microsoft IL.

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

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

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