GNUstep будет поддерживать @property и @synthesize?
Выполнение Вокруг идиомы используется, когда Вы имеете необходимость, чтобы сделать что-то вроде этого:
//... chunk of init/preparation code ...
task A
//... chunk of cleanup/finishing code ...
//... chunk of identical init/preparation code ...
task B
//... chunk of identical cleanup/finishing code ...
//... chunk of identical init/preparation code ...
task C
//... chunk of identical cleanup/finishing code ...
//... and so on., Чтобы постараться не повторять весь этот избыточный код, который всегда выполняется "вокруг" Ваших фактических задач, Вы создали бы класс, который заботится о нем автоматически:
//pseudo-code:
class DoTask()
{
do(task T)
{
// .. chunk of prep code
// execute task T
// .. chunk of cleanup code
}
};
DoTask.do(task A)
DoTask.do(task B)
DoTask.do(task C)Эта идиома перемещает весь сложный избыточный код в одно место и оставляет Вашу основную программу намного более читаемой (и удобный в сопровождении!)
Смотрят на это сообщение для примера C#, и эта статья для примера C++.
3 ответа
Это несколько месяцев поздно, но ответ - да; GNUstep будет поддерживать функции Objective-C 2.0 (а также блоки). На данный момент все более-менее реализовано, но требует тестирования и отладки. Для этих функций требуется Clang, а не gcc, и в настоящее время вам необходимо использовать магистральную версию.
См. Объяснение Дэвида Чизнолла в этом потоке для получения более подробной информации: http://groups.google.com/group/gnu.gnustep.discuss/browse_thread/thread/b0a5fa4e3be71bb1#
Я не уверен, последует ли реализация Objective-C GNUstep примеру Apple в синтезе аксессуаров / мутаторов, но если вы пытаетесь создать приложение для Mac, Windows и Linux, GNUstep, вероятно, не лучший выбор. Перенести код из Cocoa в GNUstep должно быть довольно легко (и вы можете даже написать макрос для преобразования деклараций свойств), но очень немногие люди используют GNUstep в Linux и еще меньше в Windows. Мне нравится идея кроссплатформенной реализации OpenStep, но на данный момент она непрактична с точки зрения принятия.
Нет, я не знаю, есть ли планы по поддержке свойств, но если GNUstep планирует оставаться жизнеспособным (даже если только в той ограниченной степени, в которой это происходит сейчас), это должно быть приоритет. Если GNUstep не решит принять функции Objective-C 2.0, разрыв между ним и реализацией Apple сделает написание хорошего кроссплатформенного кода все труднее. (Для большинства разработчиков это уже практически бессмысленно.)
Хотя я обычно ненавижу ответы, в которых по сути говорится: «Не делай этого, это плохая идея», я должен согласиться с @Jonathan в этом вопросе, особенно с точки зрения практичность. Хотя код может компилировать кросс-платформенный, если пользователям нужно установить среду выполнения только для того, чтобы использовать ваше приложение, вероятность того, что кто-то будет использовать ваше приложение, значительно снижается.
Этот SO-ответ хорошо резюмирует. Предлагаю прочитать его и сделать свой вывод.
Также стоит учесть, что тег « objective-c» содержит более 3280 вопросов, а «gnustep» - 9. I Я не говорю, что количество вопросов - это показатель качества, но это параллель с активностью и интересом, и, вполне возможно, с небольшим количеством людей, имеющих опыт работы с GNUstep на этом сайте. Таким образом, у вас меньше шансов получить хорошую помощь, если вы решите пойти по пути, который вы рассматриваете.
Между прочим, менталитет избегания новых функций во имя совместимости - это поведение «наименьшего общего знаменателя» это, в конечном итоге, сделает ваш код менее элегантным и менее «функциональным». Это похоже на кодирование только с API, доступным на 10. 2 или 10.3 - любой недавний разработчик OS X или iPhone скажет вам, что он предпочел бы воспользоваться преимуществами новых интересных функций, а не ограничениями прошлого. В наши дни для новых приложений почти всегда требуется версия 10,5 - поддержка старых версий более характерна для уже установленного программного обеспечения, имеющего обратную совместимость, и многие приложения со временем даже отказываются от старых ОС.
Если вы планируете продать приложение, используйте только API-интерфейсы, совместимые с GNUstep, серьезно ограничат ваш рынок и даже фундаментально ограничат ваше приложение, включая уровень полировки и функциональности, на которые вы можете надеяться. Даже если приложение не будет коммерческим, в целом есть смысл использовать язык и фреймворки, которые лучше всего подходят для данной платформы. Если вам действительно нужна кроссплатформенная поддержка, Java, скорее всего, поможет вам сблизиться, избавившись от изжоги. (Java определенно не мой любимый язык, и это не какао, но он делает многие вещи хорошо.) Хотя проблема языковой версии для разных клиентов и платформ по-прежнему остается той же, по крайней мере, он разработан , чтобы быть перекрестным -платформа, и все потребительские платформы имеют надежную поддержку Java.