Комментарии 18
А к чему имя метода класса? Давайте больше
@implementation SomeClass
-(void):(id)m
{
printf(@" HELLO: %s", [m UTF8String]);
}
end
//вместо обычно длинных имен классов можно работать с их динамическими идентификаторами
Class UTBVC = [UITableViewController class];
id exemTBVC = [[UTBVC alloc] init];
//метод class бывает и для экземляра
id nextTBVC = [[[exemTBVC class] alloc] init];
//Много раз вызываем эти длиннющие имена методов — НЕ беда
SEL Method1 = selector(setTableViewDataSource:);
SEL Method2 = selector(setChildViewController:);
//Так ведь лаконичнее?
[nextTBVC performSelector:a1];
Я ничего не забыл? Вообще этот язык изобилует возможностями строгания костылей и извратов.
@implementation SomeClass
-(void):(id)m
{
printf(@" HELLO: %s", [m UTF8String]);
}
end
//вместо обычно длинных имен классов можно работать с их динамическими идентификаторами
Class UTBVC = [UITableViewController class];
id exemTBVC = [[UTBVC alloc] init];
//метод class бывает и для экземляра
id nextTBVC = [[[exemTBVC class] alloc] init];
//Много раз вызываем эти длиннющие имена методов — НЕ беда
SEL Method1 = selector(setTableViewDataSource:);
SEL Method2 = selector(setChildViewController:);
//Так ведь лаконичнее?
[nextTBVC performSelector:a1];
Я ничего не забыл? Вообще этот язык изобилует возможностями строгания костылей и извратов.
Разве swift не лучше для этого подходит?
На данный момент я не воспринимаю Swift всерьез, с ним слишком много проблем на практике. А для тестовых проектов/изучения его возможностей есть Playgrounds.
Каких, например, проблем?
Насколько я понимаю, язык развивается и код который ранее собирался уже приходится править ради совместимости.
Примеры с github.com/matteocrippa/awesome-swift собираются не все. Разбираться же с ошибками для языка который изучаешь — не здорово.
Примеры с github.com/matteocrippa/awesome-swift собираются не все. Разбираться же с ошибками для языка который изучаешь — не здорово.
присоединяюсь к вопросу о проблемах.
- Xcode постоянно крашится на swift-проектах.
- Он не просто крашится, но иногда выдает взаимоисключающие ошибки компиляции.
- Спецификация языка только совсем недавно достигла 1.0.
- Очень много уже написанного кода obj-c необходимо использовать — лишние bridge headers. Писать на swift, ради swift?
- Производительность пока под очень большим вопросом. Во всех тестах на данный момент в разы уступает obj-c.
Уверен, все будет исправлено со временем. Но сейчас просто невозможно использовать Swift в production.
Все, что вы говорите имеет место быть, но мы таки юзаем Swift для продакшена(тот случай, когда пишем на свифте ради свифта). Вот, через недельку в аппстор будем релизиться, если заказчик не решит дизайн немного «улучшить».
Геммороя хватает, но преимущества от использования языка таки ощущаются.
Геммороя хватает, но преимущества от использования языка таки ощущаются.
Не могли бы вы привести результаты бенчмарков?
Лично я не проверял, я не работаю с swift не только по этой причине.
Вот хороший пример, можно проследить, как производительность улучшается с новыми версиями SDK:
stackoverflow.com/questions/24101718/swift-performance-sorting-arrays
Вот хороший пример, можно проследить, как производительность улучшается с новыми версиями SDK:
stackoverflow.com/questions/24101718/swift-performance-sorting-arrays
Да, спасибо, такой источник нам известен. Собственно, он полностью противоречит вашему заявлению о том, что во всех тестах Swift код разительно уступает Objective-C по производительности.
На самом деле, из перечисленных вами пунктов, имеют место только проблема с Xcode + сомнительные ошибки компиляции (противоречивых не встречал, но сообщения бывают, что называется, misleading). Гораздо большая неприятность — это то, что нет разумного способа собрать Swift библиотеку и использовать ее в приложении под iOS >= 7.0/7.1.
Интеграция с Objective-C кодом работает в свою очередь очень хорошо даже в больших проектах.
На самом деле, из перечисленных вами пунктов, имеют место только проблема с Xcode + сомнительные ошибки компиляции (противоречивых не встречал, но сообщения бывают, что называется, misleading). Гораздо большая неприятность — это то, что нет разумного способа собрать Swift библиотеку и использовать ее в приложении под iOS >= 7.0/7.1.
Интеграция с Objective-C кодом работает в свою очередь очень хорошо даже в больших проектах.
НЛО прилетело и опубликовало эту надпись здесь
Bash, Python — куда более подходящие инструменты, когда я хочу проверить простую категорию над NSDate для дальнейшего использования в своих проектах? Или когда мне надо отсортировать и сгенерировать новый plist в bundle проекта — obj-c код я напишу никуда не подсматривая, а в bash я понятия не имею, как это делать.
Статья про то, как быстрые хаки делать на одном файле, а не городить xcode-проект, а не про то, что нужно obj-c вместо bash использовать :)
Статья про то, как быстрые хаки делать на одном файле, а не городить xcode-проект, а не про то, что нужно obj-c вместо bash использовать :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Минимализм Objective-C