Комментарии 7
Прекрасный набор костылей. Благодарю от имени всей нашей палаты!
на тему врапера — это тихий ужас. Допустим у меня обж-с приложение, и если я захочу использовать данный сдк, то мне прийдется включать еще и свифт рантайм. +30 метров к весу аппы. Имхо, правильнее написать данный сдк на обж-с с нормальными nullable annotation (и как бонус — лепить свифт обвертку для него — пример facebook skd) или поддерживать 2 паралельные версии на свифте и обж-с (имхо, излишенство, хватит и первого варианта)
Все верно, только изначальные обстоятельства диктовали обратоное.
Ну, предположим, все хотят писать и пишут на Swift. А тут кто-то всплыл с legacy-проектом на Objctive-C. И ему надо тоже эту либу, которая на Swift. И надо примерно сейчас. Писать новую либу на Objective-C? Да, это самое правильное. Да только либа на Swift уже занисает примерно 10 тыс. строк, а на Objective-C займет все 20. На это может не оказаться ресурсов и времени. А потом еще придется тянуть две версии (баги там исправлять, фичи новые добавлять) – тратить на каждую новую задачу в два раза больше времени.
Описанный опыт не претендует на то, чтобы называться хорошей практикой (понятно, что такого плана оберки – это костыли), а просто представляет собой один из путей существования в описанных обстоятельствах. Или, скажем, вовсе академический эксперимент.
Ну, предположим, все хотят писать и пишут на Swift. А тут кто-то всплыл с legacy-проектом на Objctive-C. И ему надо тоже эту либу, которая на Swift. И надо примерно сейчас. Писать новую либу на Objective-C? Да, это самое правильное. Да только либа на Swift уже занисает примерно 10 тыс. строк, а на Objective-C займет все 20. На это может не оказаться ресурсов и времени. А потом еще придется тянуть две версии (баги там исправлять, фичи новые добавлять) – тратить на каждую новую задачу в два раза больше времени.
Описанный опыт не претендует на то, чтобы называться хорошей практикой (понятно, что такого плана оберки – это костыли), а просто представляет собой один из путей существования в описанных обстоятельствах. Или, скажем, вовсе академический эксперимент.
так то оно да, но ведь уже была либа на обж-с. Что-то не сходится с начальными условиями.
Имхо, использовать свифт как основной язык для стороней либы до ABI это немного не обдуманый шаг.
Имхо, использовать свифт как основной язык для стороней либы до ABI это немного не обдуманый шаг.
Это да, действительно либа была раньше на Objective-C, но это, можно сказать, была и не она вовсе – было уже проще написать новую, чем пытаться менять старую. Для новой выбрали Swift с прицелом на будущее и, конечно, соблазнившись скоростью и простотой написания и поддержки – немаловажные плюсы, на мой взгляд. Без ABI – это, безусловно, минус, но пара десятков Мб в современных реалиях – на мой взгляд, не критично. (Telegram X на 40 Мб тяжелее старого приложения еще даже не догнав его по функционалу – кажется, это мало кого волнует. Меня – точно не очень.) Зато Swift и работает потенциально быстрее. В общем, я бы сказал, что у каждого подхода есть свои плюсы и минусы.
Для того, чтобы иметь возможность использовать Swift-код внутри Objective-C-проекта в общем случае, необходимо создать так называемый Bridging Header.
Неправда. Bridging header нужен для использования objc-кода в swift'e:
developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/MixandMatch.html
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Совместимый с «Objective-C» «Swift»-код