На эту тему лучше почитать документацию, тем более, что есть и на русском языке в открытом доступе документация для Swift 2, но совместимость с Objective-C — это последнее, что я бы отметила, это было сделано мимо ходом, но с большой любовью к Objective-C. Они продолжают совершенствовать Objective-C, чтобы осуществлялась практически «бесшовная» работа Swift и Objective-C.
Проходя мимо, вы, возможно, не в курсе, что на Swift 1.x вам никто и не предлагал разрабатывать промышленные библиотеки, хотя смельчаки, конечно, находились, потому что это совершенно новый язык и никто не знал, куда он «вывернет». Были прогнозы, что он вообще уйдет в сторону функционального программирования. Но прошел год, когда весь мир участвовал в отладке Swift, и сейчас мы получили не только новый язык Swift 2, но и новые концепции программирования — помимо Объектно-Ориентированного Программирования (OOП), которое было там изначально, помимо элементов Функционального Программирования, еще и Протоколо-Ориентированное Программирование. Кроме того язык очень краткий и очень красивый. Программирование на нем — очень увлекательное занятие. Так что странного ничего нет. Пробуйте. Я думаю он и вас не оставит равнодушным.
Почему забили? Нет, они обещали к концу 2015 года. Все будет. Они очень заинтересованы в продвижении Swift. По-моему даже Windows будут что-то реализовывать у себя для разработки приложений на Swift. Если вы заметили, то Microsoft на последнем Keynote первыми демонстрировали разработку Microsoft Office для iOS. Это необычно.
Я не очень поняла ваше замечание. От 0.5 к 0.6 — это больше или меньше 1.2 от 2.0? Но, если по делу, то переходить очень легко — работает автоматическая миграция от Swift 1.2 к Swift 2.0 и работает очень хорошо, даже для больших проектов — все попробовала. Остаются только мелочи, которые легко поправить, если знаешь, как это должно быть.
Почему не имеет значения? На графике есть оси, но могут быть и другие графические элементы, может быть несколько графиков, а построение конкретного графика yForX отдается на откуп пользователю: хочет строит, хочет — нет. Эту ошибку не спрячешь — она сразу себя покажет на графике.
Но в некоторых случаях, я с вами согласна, наличие замыкания обязательно. Например, если вы удалили функцию в строке в Popover, то вам нужно обязательно синхронизировать это удаление с Моделью в Controller. Здесь замыкание не может быть Optional.
Для моей реализации в Swift это не является недостатком, так как я намеренно сделала переменную-замыкание yForX Optional, то есть графика может и не быть
var yForX: yFunctionX?
и использую я ее как Optional при построении графика
if let y = (self.yForX)?(x: Double ((point.x - origin.x) / scale)) {
. . . .
Название функции заключается в круглые скобки и ставится знак? вопроса для корректного построения цепочки Optionals. В случае, если замыкание -переменная yForX не определена в GraphViewController, то аварийного завершения приложения не будет — просто не построится график.
В Objective-C нет Optional значений. Там в случае не определения замыкания, приложение закончится аварийно.
Спасибо большое.
Действительно все понятно и достаточно кратко в пределах возможностей Objective-C.
Я думаю, этот вариант стоит попробовать тем, кто программирует на Objective-C и не только.
Да, я соглашусь с вашим замечанием относительно того, что в моей статье закралась неточность относительно использования замыканий (блоков) вместо делегирования в Objective-C.
Спасибо вам за очень обстоятельное разъяснение и ссылку на библиотеку.
Я внесла необходимые изменения в статью. Действительно, мой опыт использования замыканий в Objective-C для взаимодействия между View и Сontroller и между различными MVC ограничен.
В своей статье я вовсе не хочу сравнивать использование замыканий в Objective-C и в Swift, я хочу сказать: " Смотрите, как просто этим пользоваться в Swift. Не нужны никакие дополнительные библиотеки, никакие вспомогательные протоколы и делегаты. Достаточно вложить здравый смысл в простой и понятный синтаксис Swift."
Пользуясь тем, что есть возможность поговорить с умным собеседником, не могли бы вы для полноты картины привести простой, как на Swift, код на Objective-C для простого примера, указанного в статье, когда есть GraphView и GraphViewController, а GraphView запрашивает данные о зависимости y = f(x).
Для Swift это выглядит так:
GraphView
Objective-C — прекрасный язык, никто не спорит.
Но в пользовательском коде можно редко увидеть использование блоков вместо делегирования.
Я не знаю, что останавливает программистов.
А в Swift это выглядит просто и красиво.
Сравните простейший пример использования замыканий.
Objective C
NSMutableArray *funcs = [[NSMutableArray alloc] init];
for (int i = 0; i < 10; i++) {
[funcs addObject:[^ { return i * i; } copy]];
}
int (^foo)(void) = funcs[3];
NSLog(@"%d", foo()); // logs "9"
Swift
let funcs = [] + map(0..<10) {i in { i * i }}
println(funcs[3]()) // prints 9
Мне кажется в Swift использование замыканий вместо делегирования опустит планку для разработчика.
Была идея использовать «Ход конем» в приложении «Калькулятор», когда символ с кнопки — "+", "-", «х»… — почти напрямую (может быть через Dictionary ) попадает в performOperation, но оказалось, что операторную функцию можно задавать только явно.
Так работает:
Да, «примитивная» Apple — самая успешная и дорогая компания в мире, а вы, ребята, сидите в «минусе» или в «нуле» с вашим «интеллектуальным» высокомерием.
Отличная статья — спасибо. Не знала про «Ход конем» — в книге «The Swift Programming Language» об этом — мимолетно.
К предыдущему комментарию:
«Не понимаю, зачем чего-то ждать — на Swift уже вовсю пишут „полноценные приложения“».
Статья, на мой взгляд, далеко не «средненькая». Для нас, пришедших с Objective-C и начинающих осваиваться с функциональным программированием, она очень интересная и трудная, но если ты, наконец, «продираешься» через все эти монады, апликативные функторы и т.д., а также через особенности еще молодого и иногда неустойчивого Swift, то на выходе получаешь результат, который кажется «волшебным» и просто завораживает. Вот этим чувством и результатами своей «кривой» изучения функциональных возможностей Swift (ссылка на код в «Послесловии переводчика») я и хотела поделиться с аудиторией Хабрахабра. Хотелось обсуждать эту статью с русскоязычной аудиторией и для расширения этой аудитории и сделан перевод.
Swift стал языком с двумя парадигмами: императивной и функциональной, и в него полился поток с двух сторон: «функциональщики» и c Objective-C. Мы с Вами — в разных лагерях. Поэтому то, что для Вас монада Maybe кажется ключевой, для меня она таковой не является, то, что Вам кажется комичным, для меня таковым не является, ну а «завернутый»- обернутый мне кажется несущественным, если только термин «обернутый» не является устоявшимся в функциональной русскоязычной терминологией. Но это хорошо. Все можно согласовать и вам огромное спасибо за рецензию, так как всегда ценен взгляд «с той стороны».
Наличие в скобках англоязычного эквивалента лично мне очень помогает для понимания текста, так как сама читаю на английском.
Ну а вообще, друзья! Я вас призываю не просто «пройтись на лету» по этой статье, а изучить ее в коде. Вы получите огромный опыт и многое поймете в функциональном Swift.
В плане было выложить перевод оставшихся двух статей Тони, которые написаны в продолжение этой и даже еще более интересны, хотела посмотреть как пойдет. А сейчас даже и не знаю. Может Вам предоставить приоритет? А я бы в комментариях привела некоторый интересный код.
В любом случае я за более открытый подход: нужно популяризировать знания. Может быть Хабрахабр — не лучшее для этого место: я здесь новый человек?
Жаль, что оплошности моего перевода заслонили от Вас великолепный результат статьи, ибо обсуждения самой статьи и не получилось.
Но в некоторых случаях, я с вами согласна, наличие замыкания обязательно. Например, если вы удалили функцию в строке в Popover, то вам нужно обязательно синхронизировать это удаление с Моделью в Controller. Здесь замыкание не может быть Optional.
и использую я ее как Optional при построении графика
Название функции заключается в круглые скобки и ставится знак? вопроса для корректного построения цепочки Optionals. В случае, если замыкание -переменная yForX не определена в GraphViewController, то аварийного завершения приложения не будет — просто не построится график.
В Objective-C нет Optional значений. Там в случае не определения замыкания, приложение закончится аварийно.
Действительно все понятно и достаточно кратко в пределах возможностей Objective-C.
Я думаю, этот вариант стоит попробовать тем, кто программирует на Objective-C и не только.
Спасибо вам за очень обстоятельное разъяснение и ссылку на библиотеку.
Я внесла необходимые изменения в статью. Действительно, мой опыт использования замыканий в Objective-C для взаимодействия между View и Сontroller и между различными MVC ограничен.
В своей статье я вовсе не хочу сравнивать использование замыканий в Objective-C и в Swift, я хочу сказать: " Смотрите, как просто этим пользоваться в Swift. Не нужны никакие дополнительные библиотеки, никакие вспомогательные протоколы и делегаты. Достаточно вложить здравый смысл в простой и понятный синтаксис Swift."
Пользуясь тем, что есть возможность поговорить с умным собеседником, не могли бы вы для полноты картины привести простой, как на Swift, код на Objective-C для простого примера, указанного в статье, когда есть GraphView и GraphViewController, а GraphView запрашивает данные о зависимости y = f(x).
Для Swift это выглядит так:
GraphView
GraphViewController
Для Objective-C так ...?
Но в пользовательском коде можно редко увидеть использование блоков вместо делегирования.
Я не знаю, что останавливает программистов.
А в Swift это выглядит просто и красиво.
Сравните простейший пример использования замыканий.
Objective C
Swift
Мне кажется в Swift использование замыканий вместо делегирования опустит планку для разработчика.
performOperation, но оказалось, что операторную функцию можно задавать только явно.Так работает:
А вот такой словарь:
дает ошибку.
Может быть есть идеи?
К предыдущему комментарию:
«Не понимаю, зачем чего-то ждать — на Swift уже вовсю пишут „полноценные приложения“».
Swift стал языком с двумя парадигмами: императивной и функциональной, и в него полился поток с двух сторон: «функциональщики» и c Objective-C. Мы с Вами — в разных лагерях. Поэтому то, что для Вас монада Maybe кажется ключевой, для меня она таковой не является, то, что Вам кажется комичным, для меня таковым не является, ну а «завернутый»- обернутый мне кажется несущественным, если только термин «обернутый» не является устоявшимся в функциональной русскоязычной терминологией. Но это хорошо. Все можно согласовать и вам огромное спасибо за рецензию, так как всегда ценен взгляд «с той стороны».
Наличие в скобках англоязычного эквивалента лично мне очень помогает для понимания текста, так как сама читаю на английском.
Ну а вообще, друзья! Я вас призываю не просто «пройтись на лету» по этой статье, а изучить ее в коде. Вы получите огромный опыт и многое поймете в функциональном Swift.
В плане было выложить перевод оставшихся двух статей Тони, которые написаны в продолжение этой и даже еще более интересны, хотела посмотреть как пойдет. А сейчас даже и не знаю. Может Вам предоставить приоритет? А я бы в комментариях привела некоторый интересный код.
В любом случае я за более открытый подход: нужно популяризировать знания. Может быть Хабрахабр — не лучшее для этого место: я здесь новый человек?
Жаль, что оплошности моего перевода заслонили от Вас великолепный результат статьи, ибо обсуждения самой статьи и не получилось.