Ну, это вы загнули насчет #available. Если вы писали приложения, то наверно, знаете, что первое, что вы указываете при создании проекта, это либо приложение на iOS, либо на OS, либо tvOS, либо watchOS.
Так что они никогда не перемешаются.
Да, сейчас можно писать на Swift 2.1. Посмотрите мои Задания для стэнфордских курсов на Swift здесь. Есть очень не простые.
Единственное, где Objective-C выигрывает, — это вставка C кода напрямую в Objective-C. Но они над этим работают.
Сейчас адаптирую стэнфордские курсы на русском языке на Objective-C для iOS 9, и хотя API абсолютно одинаковые для Swift и Objective-C, несопоставимо легче писать на Swift.
До Swift 2, как в Objective-C, так и в Swift 1.x, протоколы содержали только декларацию методов (это то, о чем вы говорите).
С расширениями протокола (Protocol extensions) в Swift 2, протоколы теперь могут содержать наряду с декларацией, реализацию методов по умолчанию.
Часто некоторую функциональность необходимо добавить всем типам, которые подтверждают определенный протокол (интерфейс). Например, все коллекции (протокола CollectionType) могут поддерживать концепцию создания новой коллекции на основе преобразований своих элементов.
Если в расширении протокола CollectionType реализовать эту функциональность, то все типы, которые подтверждают протокол CollectionType, автоматически получат эту функциональность совершенно бесплатно.
Расширения протоколов лежат в основе нового подхода к конструированию программного обеспечения, заявленного Apple как Протокол-Ориентированное Программирование (ПОП), существующее в Swift 2 наряду с традиционным Объектно-Ориентированное Программированием ( ООП) и элементами Функционального Программирования (ФП). Оно должно преодолеть такие проблемы ООП, как «хрупкий базовый класс» и жесткость наследования (rigidity and fragility of inheritance), «проблему ромба» (“diamond problem”), неявное разделение ссылок на объекты, необходимость частого использования «кастинга» вниз (downcasting) в переопределенных методах.
Это сплошная деза. Зачем же это делать? Это какая-то статья-провокация.
Сегодняшний Swift не имеет ничего общего с тем, что написано в этой статье.
Да, год с небольшим назад, когда Apple объявила о Swift, некоторые, конечно, решили, что им дают готовый, как всегда очень качественный продукт. Но Apple оказалась хитрее, ни для каких больших проектов Swift 1.0 никто и не предлагал.
Она заставила весь мир работать над отладкой языка Swift и очень оперативно реагировала на все хорошие предложения.
Долго сопротивлялась, но сделала очень красивую обработку ошибок в Swift. Одни операторы guard и defer чего стоят. Сейчас язык в очень хорошей форме и действительно c многими парадигмами: хочешь ООП, хочешь элементы ФП, а сейчас еще и протокол-ориентированное программирование. Он отличается от того самого первого варианта 1,5 годичной давности как мобильные телефоны 90-х годов прошлого столетия величиной с портфель от iPhone.
То что автор статьи поскулил немного 1,5 года назад еще понять можно. Но то, что переводчик выложил это сейчас можно объяснить только тем, что целый год переводил, перевел и выбрасывать жалко.
Objective-C здесь вообще не причем. Apple его очень любовно сопровождает, API фреймворков и для Swift, и для Objective-C абсолютно одинаковые. Программируйте на чем хотите.
Но программировать на Swift приятно — всем советую попробовать и есть замечательные фишки типа if #available(iOS 9, *) без которых уже трудно обходиться.
Вообще-то это нужно не столько разработчикам на Objective-C, сколько инженерам Apple для совместимости со Swift. В Swift мы теперь для этого метода видим не AnyObject, а UITableViewCell, и не нужно делать «кастинг» для обычной UITableViewCell. В Swift 2 «кастинга» стало на порядок меньше. Про Барбару Лисков тоже знаем.
Почему нет? Это означает, что я могу использовать для ячейки любой тип, у которого superclass — UITableViewCell: TweetTableViewCell, ImageTableViewCell и т.д. Это своего рода generic с ограничением: superclass — UITableViewCell. Впрочем, я не настаиваю именно на термине generic. Но это обобщенный тип специального типа с заданным superclass.
KindOf. Objects declared as __kindof types express “some kind of X” to the compiler and can be used within generic parameters to constrain types to a particular class or its subclasses. Using __kindof allows constraints to be more flexible than an explicit class, and more explicit than just using id.
Ссылка никуда не ведет кроме UITableView. Можете сказать своими словами о чем там речь? __kindof представляет собой целую группу типов и может рассматриваться как некий обобщенный (generic) тип.
Конечно, это Swift код, но обращение к С-функциям напрямую, без всяких UnsafeMutablePointer.
Вот еще один пример — вызываем функцию сортировки qsort из библиотеки strdlib.h
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».
Если хотите писать приложения в соответствии с логикой Swift, то полезно посмотреть русский перевод стэнфордских лекций «Developing iOS 8 Apps with Swift» на сайте «Разработка iOS + Swift + Objective-C». Там профессор учит писать приложения именно в соответствии с логикой Swift (Наблюдатели Свойств, вычисляемые свойства, отложенная инициализация и т.д.).
По поводу «нищевости» — увидим, по крайней мере Apple сейчас предпринимает огромные усилия, чтобы выйти из этой ниши. Даже разработала методику обучения Swift в школах. Кстати, по своим возможностям Swift превзошел Java, хотя бы в плане функционального программирования.
Вы же в switch указали переменную, по которой будете «переключаться»? Компилятору уже известно, что она Optional. Осталось только указать значения перечисления (с возможностью извлечения ассоциированных значений). И это указывается с применением точки.
Swift имеет тип Optional, который означает, что либо у вас нет значения (None), либо у вас есть некоторое значение (Some). Так как Swift разрешает иметь для перечислений enum ассоциированные значения, то Optional тип можно представить с помощью перечисления enum так:
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.
Почему нельзя перемешивать? Пожалуйста, можете использовать любые Objective-C классы в Swift проектах, для облегчения доступа к ним в Xcode 7 добавлены 3 новые возможности для Objective-C:
— nullability;
-lightweight generics;
__kindof types.
И, наоборот, можете выставить свой Swift класс для использования в Objective-C.
В Swift 2 сильно улучшено взаимодействие с С-функциями и теперь указатели на C-функции — это просто специального вида замыкания, аннотируемые атрибутом @convention.
Я хочу об этом писать во второй части.
Так что они никогда не перемешаются.
Да, сейчас можно писать на Swift 2.1. Посмотрите мои Задания для стэнфордских курсов на Swift здесь. Есть очень не простые.
Единственное, где Objective-C выигрывает, — это вставка C кода напрямую в Objective-C. Но они над этим работают.
Сейчас адаптирую стэнфордские курсы на русском языке на Objective-C для iOS 9, и хотя API абсолютно одинаковые для Swift и Objective-C, несопоставимо легче писать на Swift.
С расширениями протокола (Protocol extensions) в Swift 2, протоколы теперь могут содержать наряду с декларацией, реализацию методов по умолчанию.
Часто некоторую функциональность необходимо добавить всем типам, которые подтверждают определенный протокол (интерфейс). Например, все коллекции (протокола CollectionType) могут поддерживать концепцию создания новой коллекции на основе преобразований своих элементов.
Если в расширении протокола CollectionType реализовать эту функциональность, то все типы, которые подтверждают протокол CollectionType, автоматически получат эту функциональность совершенно бесплатно.
Расширения протоколов лежат в основе нового подхода к конструированию программного обеспечения, заявленного Apple как Протокол-Ориентированное Программирование (ПОП), существующее в Swift 2 наряду с традиционным Объектно-Ориентированное Программированием ( ООП) и элементами Функционального Программирования (ФП). Оно должно преодолеть такие проблемы ООП, как «хрупкий базовый класс» и жесткость наследования (rigidity and fragility of inheritance), «проблему ромба» (“diamond problem”), неявное разделение ссылок на объекты, необходимость частого использования «кастинга» вниз (downcasting) в переопределенных методах.
Сегодняшний Swift не имеет ничего общего с тем, что написано в этой статье.
Да, год с небольшим назад, когда Apple объявила о Swift, некоторые, конечно, решили, что им дают готовый, как всегда очень качественный продукт. Но Apple оказалась хитрее, ни для каких больших проектов Swift 1.0 никто и не предлагал.
Она заставила весь мир работать над отладкой языка Swift и очень оперативно реагировала на все хорошие предложения.
Долго сопротивлялась, но сделала очень красивую обработку ошибок в Swift. Одни операторы
guardиdeferчего стоят. Сейчас язык в очень хорошей форме и действительно c многими парадигмами: хочешь ООП, хочешь элементы ФП, а сейчас еще и протокол-ориентированное программирование. Он отличается от того самого первого варианта 1,5 годичной давности как мобильные телефоны 90-х годов прошлого столетия величиной с портфель от iPhone.То что автор статьи поскулил немного 1,5 года назад еще понять можно. Но то, что переводчик выложил это сейчас можно объяснить только тем, что целый год переводил, перевел и выбрасывать жалко.
Objective-C здесь вообще не причем. Apple его очень любовно сопровождает, API фреймворков и для Swift, и для Objective-C абсолютно одинаковые. Программируйте на чем хотите.
Но программировать на Swift приятно — всем советую попробовать и есть замечательные фишки типа
if #available(iOS 9, *)без которых уже трудно обходиться.Вот еще один пример — вызываем функцию сортировки qsort из библиотеки strdlib.h
хотя сигнатура у нее очень накрученная
в модель
то в строго типизированном языке, как Swift, получается множество вложенных if
Это и называется «pyramid of doom» (пирамида смерти), она характерна не только для Swift. В Google надо искать «pyramid of doom».
По поводу «нищевости» — увидим, по крайней мере Apple сейчас предпринимает огромные усилия, чтобы выйти из этой ниши. Даже разработала методику обучения Swift в школах. Кстати, по своим возможностям Swift превзошел Java, хотя бы в плане функционального программирования.
Когда вы задаете Optional значение, то добавляете к типу знак вопроса ?
Но как только вы это совершили, вы будете обращаться со своими переменными username и password как перечислениями — они оказались «завернутыми» в Optional тип.
Для извлечения ассоциированных значений (String, а не String? ) используется оператор switch
Вместо того, чтобы каждый раз помнить, что нужно использовать .Some и .None, предложен синтаксический сахар
В результате вы общаетесь только со своим идентификатор username и nil и знать ничего не знаете о .Some и .None.
— nullability;
-lightweight generics;
__kindof types.
И, наоборот, можете выставить свой Swift класс для использования в Objective-C.
В Swift 2 сильно улучшено взаимодействие с С-функциями и теперь указатели на C-функции — это просто специального вида замыкания, аннотируемые атрибутом @convention.
Я хочу об этом писать во второй части.