Павел
я лучше тогда на Obj-C останусь, если один фиг что там что там "попробуйте изменить способ мышления"
Anton
it’s up to u
Max
Неполноценность не ощутить, пока не попробуешь что-то другое
Павел
> Pavel то что в этих монопольных языках нет такой банальной фичи очень огорчает не шарю как там в сисярпе, но не ощущаю никакой неполноценности ) всё достаточно удобно и гибко
не вижу ничего гибкого заводить отдельный таргет для моделек например, или сервисов, а ведь это только первый уровень вложенности, бывают пакеты и неймспейсы с 10 уровнем сложенности, и как быть тогда
Max
В Свифте объективно много крутых современных фишек, но и много чего мне лично не хватает
Павел
хорошо, а анонимные классы есть?
Max
Нет
Oleksii
Неполноценность не ощутить, пока не попробуешь что-то другое
кодил на c#, кодил на objc, кодил на swift, неполноценности из-за неймспейсов не ощущаю)
Max
А ты ими на шарпе пользовался?))
Max
Или все в одном писал?
Anton
вы бы лучше озвучили задачу, которую надо решить, а то пытаетесь привычной вам отвёрткой открутить гвоздь и ругаетесь, что не работает
Oleksii
хорошо, а анонимные классы есть?
async/await тоже нету если что)
Anton
))))
Павел
А ты ими на шарпе пользовался?))
жаба, очень понравилось что однострочные функции можно сразу в коде описать
Max
вы бы лучше озвучили задачу, которую надо решить, а то пытаетесь привычной вам отвёрткой открутить гвоздь и ругаетесь, что не работает
Ну например у меня есть несколько сервисов, которые используют пару классов, я не хочу чтоб эти классы были видны во всем коде. Только сервисы - классический фасад
Eduard
неймспейсы это приятно, но уж точно не мастхев
Павел
async/await тоже нету если что)
вроде это имитируется библиотекой, как и LINQ
Max
Не мастхев, да
Max
Ну например у меня есть несколько сервисов, которые используют пару классов, я не хочу чтоб эти классы были видны во всем коде. Только сервисы - классический фасад
В итоге в Свифте надо либо все в одном файле писать и использовать fileprivate, либо каждый такой блок выносить в модуль. Для времени компиляции это ад
Anton
наоборот - сокращение времени компиляции
Max
не успел написать - да, так, а зачем пересобирать моудль?
Ага, скажи это хкоду у которого отваливается автокомплит постоянно
Anton
ну т.е. проблема в Xcode, а не в отсутствии неймспейсов?
Павел
нет я понимаю прекрасно что мы без много прекрасно обходились, но просто недоумение вызывает сунули дженерики, опционалы, кортежи и кучу всего, в неймспейсы забыли, может быть это из-за совместимости с Objective-C ?
Max
ну т.е. проблема в Xcode, а не в отсутствии неймспейсов?
А разница какая? Инструментарий не позволяет использовать этот подход с удобством. 30 модулей я не представляю сколько собираться будут
Anton
я же латтнера процитировал про неймспейсы - никто ничего не забыл - устроено иначе
Max
Изучать?) как изучать то, чего нет?)
Павел
нет, это нытье какого фига в монопольном языке нет того, что во всяких жабах и сисярпах с первых версий есть
Anton
Павел, а вот вы с какой версии на джаве пишете?
Paks
для таких в след апдейте макбучега пророчат 32 гб озу 😆
Max
Видимо у тебя проект маленький и дженерики не используешь
Max
Попробуй зависимостей побольше между модулями ебануть
Alexander
если нужны неймспейсы – делаете таргеты с фреймворками все очень логично
Max
Про вкладке в хроме согласен, но это не к месту здесь
Alexander
зачем в рамках одного таргета несколько пространств имен?
Max
потому что таргет по смыслу это не модуль
Max
таргет это таргет
Anton
вчера полдня убил на баг в swiftc vs generics - надо чётче указывтаь имплеменитруемые протоколы
Alexander
еще раз если есть необходимость в неймспейсе, тов се это можно вынести в фреймворк, так?
Павел
Павел, а вот вы с какой версии на джаве пишете?
какая разница то? Хочешь сказать, в жабу пакеты только недавно добавили?
Anton
хочу сказать, что даже джава 1.4 (про 1.2 вообще молчу) - огроменная боль в сравнении с шестёркой
Anton
это было про “а на джаве всё изначально было круто сделано”
Max
когда отваливается автокомплит, а вот он отваливается как раз когда много зависимостей между модулями
Павел
еще раз если есть необходимость в неймспейсе, тов се это можно вынести в фреймворк, так?
что делать если в проекте десятки неймспейсов? Десятки фреймворков заводить? В то время как жабаисты и шарписты просто папочки создат и хихикают ехидно?
Max
и дженериков
Anton
в 2016-м на J2ME 1.4 тоже приходится писать, вот же поворот!!!
Alexander
что делать если в проекте десятки неймспейсов? Десятки фреймворков заводить? В то время как жабаисты и шарписты просто папочки создат и хихикают ехидно?
да, десятки фреймворков потому что отдельный неймспейс = независимое пространство с кодом перекомпиливаться будут те, что изменяются, а не все при каждом билде
Anton
xcode не причём - проблема в SourceKit feat swiftc
Павел
это было про “а на джаве всё изначально было круто сделано”
нет, послы был не в жабе все круто изначально было, а в жабе такая простая возможность с первых версий есть, а тут язык начали создавать чуть ли не на 15 лет позже, и не догадались
Max
так вот был бы xcode постабильнее и время компиляции адекватное, то и хрен бы уж с неймспейсами
Anton
может таки прочитаете пост латтнера про неймспейсы?
Max
ну да, сорскит
Павел
да, десятки фреймворков потому что отдельный неймспейс = независимое пространство с кодом перекомпиливаться будут те, что изменяются, а не все при каждом билде
это конечно решение, но не могу сказать что я им удовлетворен, считаю, могли бы и ввести жабовские или шарповские модули
Anton
и не будете писать про “не догадались”
Anton
вы же не считаете себя умней создателей свфита?
Anton
https://twitter.com/clattner_llvm/status/474730716941385729
Anton
я не тебе )
Alexander
вы же не считаете себя умней создателей свфита?
+ они исходили исключительно из условий, что у них были и, грубо говоря, папочки и namespace это не самый адекватный способ разметки кода (зато самый простой)
Павел
вы же не считаете себя умней создателей свфита?
я и пытаюсь догадаться, чем они руководствовались
Max
1) латтнер писал о том, что модули должны заменять неймспейсы 2) не считаю себя умнее создателей свифта, но считаю что многие вещи в свифте делались не всегда для удобства создания больших проектов, а для уменьшения порога вхождения
Max
и они сами об этом часто говорят
Alexander
я большие проекты на свифте вижу в виде наборов фреймворков с хостом, который их крутит основная проблема сейчас в инструментарии, а не языке, имхо
Max
согласен, был бы толковый инструментарий, большинство вопросов было бы снято
Alexander
после ABI можно будет предъявлять уже, а пока пишите пропозалы в evolution, хоть чем-то разбавите access modifiers
Max
кто-нибудь кстати чекал, как модули влияют на размер приложения? у меня че-то руки не дойдут никак
Тихонов
По мне использование префикса удобно для того, что различать классы в проектах
Тихонов
Пишешь ты URLResponse, и вот хрен пойми откуда этот класс, то ли из аламофаер, то ли из стандартного юрлконнекшен, то ли твой друг вася его добавил, а так было бы написано SKURLResponse сразу понятно, твой друг вася написал или AFURLResponse - аломофаер
Тихонов
и написал ты SK… тебе сразу икскод подставил твои классы проекта, а не всего подряд
Anton
кто мешает писАть Alamofire.URLResponse ?
Anton
а эти префиксы, принятые в Obj-C от безысходности - уродливый атавизм
Max
ну чисто в абсолютном значении интересно, например, если выделить 5 классов из проекта в отдельный фреймворк - насколько выростает
Anton
с учётом внедряемого в бандл рантайма свифта - думаю можно пренебречь
Anton
в худшем случае - когда из модуля используется лишь один публичный метод, собранное статикой приложение не будет содержать независимые от этого метода объекты, а во фреймворк будут влинкованы все объекты трансляции
Anton
ну и плюс оверхед на оформление бинаря
Anton
но это обычно мелочи
Sergey
Всем привет! Как из Obj-C детектить Swift типы? Например свифтовый Dictionary SwiftNativeDictionary?
Sergey
есть задача "глубоко" конвертнуть все объекты из NSMutableDictionary в настоящие ObjC типы NSMutableDictionary или NSMutableArray. Главный NSMutableDictionary приходит из свифта, но в нем есть свифтовые типы которые не mutable и их надо конвертнуть в ObjC mutable типы