Comments 36
Спасибо за статью, отличные примеры! Вроде всё это и так знал, но всё равно такое ощущение что узнал что-то новое.
Мимо проходил. Количество ломающих изменений такое, будто переход не от 1.2 к 2.0, а от 0.5 к 0.6. Переписывать же невесело будет…
Я не очень поняла ваше замечание. От 0.5 к 0.6 — это больше или меньше 1.2 от 2.0? Но, если по делу, то переходить очень легко — работает автоматическая миграция от Swift 1.2 к Swift 2.0 и работает очень хорошо, даже для больших проектов — все попробовала. Остаются только мелочи, которые легко поправить, если знаешь, как это должно быть.
В смысле сплошником радикальные изменения синтаксиса: не просто добавление ключевых слов или изменение обработки каких-то случаев, а полное изменение назначения ключевых слов, изменение синтаксиса вызова всех функций и тому подобное. Такие изменения характерны на ранних стадиях развития до первого релиза 1.0, а потом обычно стараются не ломать всё и сразу. Если свой проект можно прогнать через конвертировалку, то как быть, например, разработчикам библиотек, которые поддерживают несколько версий? Да и как в обычном проекте быть, если главная ветка перешла на новую версию, а старые ветки тоже надо поддерживать и мержить изменения? Короче, странно всё это видеть.
Проходя мимо, вы, возможно, не в курсе, что на Swift 1.x вам никто и не предлагал разрабатывать промышленные библиотеки, хотя смельчаки, конечно, находились, потому что это совершенно новый язык и никто не знал, куда он «вывернет». Были прогнозы, что он вообще уйдет в сторону функционального программирования. Но прошел год, когда весь мир участвовал в отладке Swift, и сейчас мы получили не только новый язык Swift 2, но и новые концепции программирования — помимо Объектно-Ориентированного Программирования (OOП), которое было там изначально, помимо элементов Функционального Программирования, еще и Протоколо-Ориентированное Программирование. Кроме того язык очень краткий и очень красивый. Программирование на нем — очень увлекательное занятие. Так что странного ничего нет. Пробуйте. Я думаю он и вас не оставит равнодушным.
А, понятно, «1.0» по смыслу был «0.5», а «2.0» — что-то типа «0.9». Тогда всё встаёт на свои места. :) Традиции расстановки цифр в версиях разные, да и цифры конкурентов догонять надо… Вообще, я сторонник идей semver.org.
UFO just landed and posted this here
Почему забили? Нет, они обещали к концу 2015 года. Все будет. Они очень заинтересованы в продвижении Swift. По-моему даже Windows будут что-то реализовывать у себя для разработки приложений на Swift. Если вы заметили, то Microsoft на последнем Keynote первыми демонстрировали разработку Microsoft Office для iOS. Это необычно.
UFO just landed and posted this here
Что-то похожее уже есть) www.elementscompiler.com/elements/silver
А какие у свифта киллер-фичи кроме совместимости с Obj-C?
На эту тему лучше почитать документацию, тем более, что есть и на русском языке в открытом доступе документация для Swift 2, но совместимость с Objective-C — это последнее, что я бы отметила, это было сделано мимо ходом, но с большой любовью к Objective-C. Они продолжают совершенствовать Objective-C, чтобы осуществлялась практически «бесшовная» работа Swift и Objective-C.
UFO just landed and posted this here
Почему нельзя перемешивать? Пожалуйста, можете использовать любые Objective-C классы в Swift проектах, для облегчения доступа к ним в Xcode 7 добавлены 3 новые возможности для Objective-C:
— nullability;
-lightweight generics;
__kindof types.
И, наоборот, можете выставить свой Swift класс для использования в Objective-C.
В Swift 2 сильно улучшено взаимодействие с С-функциями и теперь указатели на C-функции — это просто специального вида замыкания, аннотируемые атрибутом @convention.
Я хочу об этом писать во второй части.
— nullability;
-lightweight generics;
__kindof types.
И, наоборот, можете выставить свой Swift класс для использования в Objective-C.
В Swift 2 сильно улучшено взаимодействие с С-функциями и теперь указатели на C-функции — это просто специального вида замыкания, аннотируемые атрибутом @convention.
Я хочу об этом писать во второй части.
Возможность подобного смешивания наложила бы существенные ограничения на сам язык и потянуло бы соответствующие недостатки из старого языка. Всё-таки Objective-С это надстройка над C. А Swift — это именно другой язык с другой внутренней архитектурой. Совместимость такого рода как реализована сейчас, на мой взгляд, является самой оптимальной. У вас есть возможность использовать языки разного уровня и типа в одном проекте и достаточно прозрачно их сшивать — и это уже очень здорово!
Да и вообще плохой это тон — мешать код разных языков в одном файле.
Да и вообще плохой это тон — мешать код разных языков в одном файле.
UFO just landed and posted this here
Разумеется это не киллер-фича, но это критически необходимая вещь для выживания любого нового языка.
Вообще в индустрии так сложилось, что каждый крупный (да и не очень крупный) игрок старается или вынужден разрабатывать свой собственный язык. И Apple просто сделала очередной необходимый шаг. Можно обожать ObjC сколько угодно, но давайте по-честному всё-таки он уже устарел, так что Apple даже несколько затянула с этим и вынуждена сейчас форсировать события. Поэтому мы наблюдаем такие частые и сильные изменения в языке.
Как бы то ни было, лично я считаю, что Swift может и не лучше других модных ныне языков (Go, C#, Rust и тд) но по крайней мере не хуже и благодаря поддержке Apple имеет хорошие шансы занять существенную долю рынка даже за пределами инфраструктуры Apple.
Вообще в индустрии так сложилось, что каждый крупный (да и не очень крупный) игрок старается или вынужден разрабатывать свой собственный язык. И Apple просто сделала очередной необходимый шаг. Можно обожать ObjC сколько угодно, но давайте по-честному всё-таки он уже устарел, так что Apple даже несколько затянула с этим и вынуждена сейчас форсировать события. Поэтому мы наблюдаем такие частые и сильные изменения в языке.
Как бы то ни было, лично я считаю, что Swift может и не лучше других модных ныне языков (Go, C#, Rust и тд) но по крайней мере не хуже и благодаря поддержке Apple имеет хорошие шансы занять существенную долю рынка даже за пределами инфраструктуры Apple.
А вот это вы зря! Только что поставил и погонял Beta релиз Xcode 7.1 (Build: 7B91b) с поддержкой Swift 2.1.
В версии 2.1 добавили возможность использования си кода без всяких бриджей (наконец то избавились от костылей что юзали раньше) :)
Более подробно можно почитать тут: https://developer.apple.com/library/prerelease/ios/releasenotes/DeveloperTools/RN-Xcode/Chapters/xc7_release_notes.html
Apple делает правильные шаги для того, чтобы заменить Objective C на более перспективный и мощный язык программирования; и как мне кажется делает это весьма успешно ;)
В версии 2.1 добавили возможность использования си кода без всяких бриджей (наконец то избавились от костылей что юзали раньше) :)
func xyz() throws {
let f = fopen("x.txt", "r")
defer { fclose(f) }
try foo(f) // f is closed if an error is propagated.
let f2 = fopen("y.txt", "r")
defer { fclose(f2) }
try bar(f, f2) // f2 is closed, then f is closed if an error is propagated.
} // f2 is closed, then f is closed on a normal path
Более подробно можно почитать тут: https://developer.apple.com/library/prerelease/ios/releasenotes/DeveloperTools/RN-Xcode/Chapters/xc7_release_notes.html
Apple делает правильные шаги для того, чтобы заменить Objective C на более перспективный и мощный язык программирования; и как мне кажется делает это весьма успешно ;)
UFO just landed and posted this here
Это не си код, это как раз самый обычный swift-код.
Конечно, это Swift код, но обращение к С-функциям напрямую, без всяких UnsafeMutablePointer.
Вот еще один пример — вызываем функцию сортировки qsort из библиотеки strdlib.h
хотя сигнатура у нее очень накрученная
Вот еще один пример — вызываем функцию сортировки qsort из библиотеки strdlib.h
хотя сигнатура у нее очень накрученная
Предыдущая версия свифт вела себя также, «без всяких UnsafeMutablePointer», разве что try и defer еще не было.
Я не понимаю о чем вы спорите, человек хотел вставлять си код, внутрь кода Свифт, вроде того как работают ассембленые вставки в си. Это невозможно сделать чисто технически, а вызывать сишные функции можно было изначально.
Я не понимаю о чем вы спорите, человек хотел вставлять си код, внутрь кода Свифт, вроде того как работают ассембленые вставки в си. Это невозможно сделать чисто технически, а вызывать сишные функции можно было изначально.
Спасибо за обзор.
У меня небольшой вопрос по синтаксису.
Скажите пожалуйста а здесь .Some это своего рода вызов статического метода из предварительно импортированного пространства имен.
Типа статического импорта в Java или C#?
У меня небольшой вопрос по синтаксису.
case let (.Some(username), .Some(password)):
print("Success!")
Скажите пожалуйста а здесь .Some это своего рода вызов статического метода из предварительно импортированного пространства имен.
Типа статического импорта в Java или C#?
Swift имеет тип Optional, который означает, что либо у вас нет значения (None), либо у вас есть некоторое значение (Some). Так как Swift разрешает иметь для перечислений enum ассоциированные значения, то Optional тип можно представить с помощью перечисления enum так:
Когда вы задаете Optional значение, то добавляете к типу знак вопроса ?
Но как только вы это совершили, вы будете обращаться со своими переменными username и password как перечислениями — они оказались «завернутыми» в Optional тип.
Для извлечения ассоциированных значений (String, а не String? ) используется оператор switch
Вместо того, чтобы каждый раз помнить, что нужно использовать .Some и .None, предложен синтаксический сахар
В результате вы общаетесь только со своим идентификатор username и nil и знать ничего не знаете о .Some и .None.
enum Optional {
case None
case Some(T)
}
Когда вы задаете Optional значение, то добавляете к типу знак вопроса ?
var username: String?
var password: String?
username = .Some("Alex")
password = .None
Но как только вы это совершили, вы будете обращаться со своими переменными username и password как перечислениями — они оказались «завернутыми» в Optional тип.
Для извлечения ассоциированных значений (String, а не String? ) используется оператор switch
Вместо того, чтобы каждый раз помнить, что нужно использовать .Some и .None, предложен синтаксический сахар
В результате вы общаетесь только со своим идентификатор username и nil и знать ничего не знаете о .Some и .None.
Да это я все понял, спасибо. Вопрос был немного о другом, что именно означает точка перед .Some это логически должно быть эквивалентно Optional.Some. Просто мне, человеку с багажом Java/C# точка бьет в глаз, вот и мучаю себя вопросом эквивалентно ли это статическим импортам.
Точка означает обращение к перечислению. Да это эквивалентно Optional.Some. Как к нему обратиться в Java?
Вы же в switch указали переменную, по которой будете «переключаться»? Компилятору уже известно, что она Optional. Осталось только указать значения перечисления (с возможностью извлечения ассоциированных значений). И это указывается с применением точки.
Спасибо за статью, интересно. Пишу на Swift, но скорее в С/ObjC-стиле, так что узнал много нового.
Вообще, что в ObjC что в Swift, огорчает что это уж больно нишевые языки, которые практически не имеют хождения за пределами экосистемы Apple (но видимо это вечная участь iOS-разработчиков, увы). Уж лучше бы в Apple вторым языком яву выбрали :)))
Вообще, что в ObjC что в Swift, огорчает что это уж больно нишевые языки, которые практически не имеют хождения за пределами экосистемы Apple (но видимо это вечная участь iOS-разработчиков, увы). Уж лучше бы в Apple вторым языком яву выбрали :)))
У Swift как раз есть шансы выбраться за пределы этой экосистемы. Тут больше роли играет не сам язык, а политика компании.
Если хотите писать приложения в соответствии с логикой Swift, то полезно посмотреть русский перевод стэнфордских лекций «Developing iOS 8 Apps with Swift» на сайте «Разработка iOS + Swift + Objective-C». Там профессор учит писать приложения именно в соответствии с логикой Swift (Наблюдатели Свойств, вычисляемые свойства, отложенная инициализация и т.д.).
По поводу «нищевости» — увидим, по крайней мере Apple сейчас предпринимает огромные усилия, чтобы выйти из этой ниши. Даже разработала методику обучения Swift в школах. Кстати, по своим возможностям Swift превзошел Java, хотя бы в плане функционального программирования.
По поводу «нищевости» — увидим, по крайней мере Apple сейчас предпринимает огромные усилия, чтобы выйти из этой ниши. Даже разработала методику обучения Swift в школах. Кстати, по своим возможностям Swift превзошел Java, хотя бы в плане функционального программирования.
Это делает guard естественным способом проверки нефатальных предварительных условий без использования «пирамиды сметри»
А что за «пирамиды сметри»? Ничего не нагуглил по этому термину.
Если вам нужно парсить JSON данные
в модель
то в строго типизированном языке, как Swift, получается множество вложенных if
Это и называется «pyramid of doom» (пирамида смерти), она характерна не только для Swift. В Google надо искать «pyramid of doom».
{
"stat" : "ok",
"blogs" : {
"blog" : [
{
"needspassword" : true,
"id" : 73,
"name" : "Bloxus test",
"url" : "http:\/\/remote.bloxus.com\/"
},
{
"id" : 74,
"name" : "Manila Test",
"needspassword" : false,
"url" : "http:\/\/flickrtest1.userland.com\/"
}
]
}
}
в модель
struct Blog {
let id: Int
let name: String
let needsPassword : Bool
let url: NSURL
}
то в строго типизированном языке, как Swift, получается множество вложенных if
func parseBlog(blogDict: [String:AnyObject]) -> Blog? {
if let id = blogDict["id"] as NSNumber? {
if let name = blogDict["name"] as NSString? {
if let needsPassword = blogDict["needspassword"] as NSNumber? {
if let url = blogDict["url"] as NSString? {
return Blog(id: id.integerValue,
name: name,
needsPassword: needsPassword.boolValue,
url: NSURL(string: url)
)
}
}
}
}
return nil
}
Это и называется «pyramid of doom» (пирамида смерти), она характерна не только для Swift. В Google надо искать «pyramid of doom».
Sign up to leave a comment.
«Что нового в Swift 2?» на примерах