Будет ли GNUstep поддерживать @property и @synthesize?

Question

Я работаю над приложением Cocoa с намерением использовать его в Windows и Linux с помощью GNUstep. До сих пор я избегал Objective-C 2.0, но мне очень хотелось бы использовать по крайней мере свойства. То, что Google, кажется, говорит мне (хотя у меня проблемы с поиском по этому вопросу) заключается в том, что в настоящее время функции Objective-C 2.0 не работают с GNUstep. Кто-нибудь знает, есть ли планы для GNUstep для поддержки @property и @synthesize?

Я также задаюсь вопросом, есть ли хорошая стратегия для «расширения» их? Я мог бы, конечно, представить себе программу, которая могла бы расширять код с помощью @property и @synthesize в код, который не использует никаких функций Objective-C 2.0, но я беспокоюсь, что спрос на такой предмет не так уж и очень большой, поэтому я, вероятно, t найти его.

Считаете ли вы, что GNUstep будет поддерживать @property и @synthesize в следующем году или около того?

Answer 1

Это несколько месяцев спустя, но ответ да; GNUstep будет поддерживать функции Objective-C 2.0 (а также блоки). В настоящее время все более или менее реализовано, но требует тестирования и отладки. Для этих функций требуется Clang, а не gcc, и в настоящее время вам необходимо использовать версию trunk.

объяснение знакомства Дэвида Chisnall в этой теме для более подробной информации: http://groups.google.com/group/gnu.gnustep.discuss/browse_thread/thread/b0a5fa4e3be71bb1#

Answer 2

Я не уверен, что реализация Objective-C GNUstep будет следовать примеру Apple в синтезе accessor/mutator, но если вы пытаетесь создать приложение для Mac, Windows и Linux, GNUstep, вероятно, не самый лучший выбор. Достаточно легко перенести код из Cocoa в GNUstep (и вы могли бы даже написать макрос для преобразования объявлений свойств), но очень немногие люди используют GNUstep для Linux и даже меньше в Windows. Мне нравится идея кросс-платформенной реализации OpenStep, но на данный момент она не очень практична, усыновлена.

Answer 3

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

Хотя я обычно ненавижу ответы, которые по сути говорят «не делай этого, это плохая идея», я должен согласиться с @Jonathan на этом, особенно с точки зрения практичности. Хотя код может скомпилировать кросс-платформу, если пользователям необходимо установить среду выполнения только для использования вашего приложения, вероятность того, что кто-то будет использовать ваше приложение, значительно уменьшится.

This SO answer подводит итог. Я предлагаю прочитать его и сделать свой собственный вывод.

Следует также учитывать, что тег «objective-c" имеет более 3280 вопросов, а "gnustep" имеет 9. Я не говорю, что объем вопросов - это показатель качества, но он параллелен деятельности и интересам, и вполне возможно поэтому у вас меньше шансов получить хорошую помощь, если вы решите пойти по интересующему вас пути.

К слову, менталитет избежать новых функции в названии совместимости - это поведение «наименее общего знаменателя», которое в конечном итоге сделает ваш код менее изящным и менее «функциональным». Он похож на только кодирование с API, доступным на 10.2 или 10.3, - любой недавний OS X или разработчик iPhone скажут вам, что они предпочли бы е преимущество новых интересных функций, и не препятствовать прошлым ограничениям. В наши дни новые приложения почти всегда требуют 10,5 - поддержка более старых версий более характерна для установленного программного обеспечения, которое поддерживает обратную совместимость, и многие приложения даже теряют старые ОС со временем.

Если вы планируете продавать приложение, использование только совместимых с GNUstep API-интерфейсов сильно ограничит ваш рынок и даже ограничит ваше приложение фундаментальными способами, в том числе уровень полирования и функциональности, которые вы можете надеяться достичь. Даже если приложение не будет коммерческим, обычно имеет смысл использовать язык и фреймворки, которые лучше всего подходят для данной платформы.Если вы действительно ищете кросс-платформенную поддержку, Java, скорее всего, приблизит вас к более низкой изжоге. (Java, определенно, не мой любимый язык, и это не Cocoa, но он делает много всего хорошего.) Хотя по-прежнему существует та же проблема языковой версии для клиентов и платформ, по крайней мере, это , разработанный для кросс-платформенной и все потребительские платформы имеют прочную поддержку Java.