Опасения понятны и оправданны. У всего есть своя цена, и за динамизм тоже приходится платить. Тут вопрос в том, кому что дороже. Мне лично нравится наличие свободы выбора. Хочу – пишу безопасно, а хочу – срезаю углы. Objective-C более толерантный язык.
Пару фишечек не знал, в частности про засахаривания боксинга структур.
Добавлю свои 5 капель керосина в холивар Objective-C vs Swift в пользу старого доброго. Когда я после 10-летнего опыта разработки на C++ перешёл в мир Objective-C, для меня этот язык со странным синтаксом стал как глоток свежего воздуха.
Во-первых, в Objective-C идеально соблюден баланс динамической и статической типизации. Мы можем брать лучшее из обоих миров. Выше был справедливый коментарий от Agranatmark, что представленные в статье премы – это с точки зрения Swift костыль для внедрения статики в мир Objective-C. Но есть и контрпримеры. Например, кодогенерация на основе Sourcery – не что иное как костыль с точки зрения Objective-C для внедрения метапрограммирования в Swift. Чтобы не быть слишком абстрактным, приведу в пример пару своих библиотек, которые элегантно делаются на Objective-C и волосато на Swift:
POSAllocationTracker. Автоматическая детекция утечек объектов. Используется в юнит-тестах на утечки и в дебажной сборке для обнаружения утечек важных с точки зрения бизнес-логики объектов. Например, IoC-контейнер может не просто вернуть некий объект со скопом Singleton, но и перед созданием проверить, реально ли этого объекта не существует в памяти из-за допущенной утечки.
POSLens. Обобщенные функциональные линзы в 100 строчек. В противовес лаконичной реализации на Objective-C в этой статье показывается, как их сделать для Swift и порешать бойлерплейт с помощью Sourcery.
На мой взгляд, статическая типизация важна, но не настолько, чтобы жертвовать динамизмом целиком и полностью. Swift в этом отношении чересчур ортодоксален.
Во-вторых, Objective-C более прост в освоении, чем Swift. Всего 120 страниц в официальном мануале против официального 2-томника Swift в iBooks. Количество синтаксических нюансов в последнем уже довольно изрядно, и ветерок C++ из прошлого вполне ощущается. Не зря Дейв Абархамс одновременно is a member of the Swift language core team and… also founding member of Boost.org and a former participant in the ISO C++ standards committee. Как любителю метапрограммирования с использованием Boost MPL и Fusion мне понятен и симпатичен этот путь Swift, но шаблоны в C++ сложны, и в плюсовом сообществе отношение к ним неоднозначное. В поддежку мнения о нарастающей сложности Swift приведу также вот этот недавний замечательный тредик в Twitter.
I found ObjC much easier to learn & teach than Swift. The main difference is you really want a formal introduction to ObjC that takes about a week (the BNR book for instance). Swift you can play with and guess the bare basics, but after that, the learning curve is much steeper.
В статье описываются все составляющие паттерна исключительно в иллюстративных целях. Разумеется, нет никакого смысла реализовывать очередь, планировщик и ранлуп самостоятельно. NSOperationQueue вполне может подойти в качестве базового блока для реализации паттерна, но сама по себе она его не реализует. Чтобы паттерн состоялся, необходимо гарантировать следующее:
Объекты используют прямые вызовы друг к другу только при условии, что с ними проассоциирована одна и та же очередь. Если она не проассоциирована вообще, то тогда считается, что они должны исполняться в контексте главного потока.
Если с объектами проассоциированы разные очереди, то вызов метода должен происходить опосредовано через исполнение NSOperation.
Никакие 2 операции в одной очереди не должны исполняться параллельно. Т. е. либо в качестве underlyingQueue объекта NSOperationQueue должна быть serial queue, либо максимальное количество параллельно исполняемых операций должно равняться 1.
Ну и, конечно же, в production-коде крайне желательно обеспечить автоматическую проверку исполнения этих трех пунктов.
Одна из неприятных черт RAC – это магия управлением времени жизни объектов. Из-за нее очень легко допустить утечку каких-нибудь RACDisposable. Но он все равно настолько хорош, что я написал библиотеку для трекинга утечек памяти и пишу юнит-тесты на утечки RACDisposable, как, например здесь.
Еще один подход в копилку — внешние тулзы. Например, мне интересно попробовать xcres. То же самое, что с NSLocalizedString, только позволяет проверять наличие необходимых локализационных ключей на этапе компиляции.
Да, затея была не для слабонервных. Были моменты, когда я тоже подумывал бросить это дело и пойти другим проверенным и одновременно более легким путем. Например, можно было бы вручную формировать HTTP пакеты типа multipart/form-data. Но, очевидно, такой подход менее гибок по сравнению с реализацией собственного потока. Во-первых, он узкоспециализирован, а во-вторых, слабо интегрирован с сетевым слоем iOS SDK. Так, сейчас представленный в статье поток мы намерены использовать и для другой цели — формирования миниатюр фотографий из галереи.
Спасибо за статью. Буду ждать продолжения.
А кто-нибудь уже пробовал CppCMS — Web фреймворк от создателя Boost.Locale? Было бы интересно сравнить его с FastCGI-Deamon.
Приложение с простыми контролами и смотрится просто. Приложение же, созданное в соответствии с гайдами, смотрится гораздо современнее и оттого привлекательнее.
Я думал об этом, но сразу отказался по нескольким причинам:
1. Виджеты для S^1 и QML для S^3 — это 2 кодовые базы для слоя представления, что плохо.
2. Самостоятельно реализовывать на виджетах контролы, соответствующие Symbian Design Guidelines, весьма длительная и кропотливая работа, а в случае с Qt Quick Components мы получаем их из коробки.
3. Виджеты не позволяют реализовывать интерфейс в соответствии с паттерном MVVM. Можно, конечно, ради этого накрутить свой фреймворк поверх виджетов, но это опять-таки трудозатратно.
Опасения понятны и оправданны. У всего есть своя цена, и за динамизм тоже приходится платить. Тут вопрос в том, кому что дороже. Мне лично нравится наличие свободы выбора. Хочу – пишу безопасно, а хочу – срезаю углы. Objective-C более толерантный язык.
Пару фишечек не знал, в частности про засахаривания боксинга структур.
Добавлю свои 5 капель керосина в холивар Objective-C vs Swift в пользу старого доброго. Когда я после 10-летнего опыта разработки на C++ перешёл в мир Objective-C, для меня этот язык со странным синтаксом стал как глоток свежего воздуха.
Во-первых, в Objective-C идеально соблюден баланс динамической и статической типизации. Мы можем брать лучшее из обоих миров. Выше был справедливый коментарий от Agranatmark, что представленные в статье премы – это с точки зрения Swift костыль для внедрения статики в мир Objective-C. Но есть и контрпримеры. Например, кодогенерация на основе Sourcery – не что иное как костыль с точки зрения Objective-C для внедрения метапрограммирования в Swift. Чтобы не быть слишком абстрактным, приведу в пример пару своих библиотек, которые элегантно делаются на Objective-C и волосато на Swift:
На мой взгляд, статическая типизация важна, но не настолько, чтобы жертвовать динамизмом целиком и полностью. Swift в этом отношении чересчур ортодоксален.
Во-вторых, Objective-C более прост в освоении, чем Swift. Всего 120 страниц в официальном мануале против официального 2-томника Swift в iBooks. Количество синтаксических нюансов в последнем уже довольно изрядно, и ветерок C++ из прошлого вполне ощущается. Не зря Дейв Абархамс одновременно is a member of the Swift language core team and… also founding member of Boost.org and a former participant in the ISO C++ standards committee. Как любителю метапрограммирования с использованием Boost MPL и Fusion мне понятен и симпатичен этот путь Swift, но шаблоны в C++ сложны, и в плюсовом сообществе отношение к ним неоднозначное. В поддежку мнения о нарастающей сложности Swift приведу также вот этот недавний замечательный тредик в Twitter.
Ну и, конечно же, в production-коде крайне желательно обеспечить автоматическую проверку исполнения этих трех пунктов.
github.com/relatedcode/ParseAlternatives
А кто-нибудь уже пробовал CppCMS — Web фреймворк от создателя Boost.Locale? Было бы интересно сравнить его с FastCGI-Deamon.
1. Виджеты для S^1 и QML для S^3 — это 2 кодовые базы для слоя представления, что плохо.
2. Самостоятельно реализовывать на виджетах контролы, соответствующие Symbian Design Guidelines, весьма длительная и кропотливая работа, а в случае с Qt Quick Components мы получаем их из коробки.
3. Виджеты не позволяют реализовывать интерфейс в соответствии с паттерном MVVM. Можно, конечно, ради этого накрутить свой фреймворк поверх виджетов, но это опять-таки трудозатратно.