Д
Теперь у тебя ConcreteVC имеет нормальную типизацию для associatedType
и код уходит в экстеншен протокола, по нормальному, так как НОРМАЛЬНО ТИПИЗИРОВАНО
Size: a a a
2021 April 19
mm
Д
Ну это могло бы быть решением (технически), если бы сториборды нормально поддерживали контроллеры-дженерики
DK
ну не знаю чем мой пример отличается от того что было раньше но вот
В
Вам ехать или шашечки? 😄
У тебя DI через сториборды?
У тебя DI через сториборды?
В
По сути ты сделал тож самое – типизировал по нормальному.
DN
чет не нахожу такого
DK
ну так и было вот тут. в чем проблема то?
В
А не дженерик дженериком погоняешь
Д
так а при чем тут DI. Если верстка идет в сторибордах, то как ты укажешь тип VC-дженерика в сториборде?
В
Его пугает зависимость VC от конкретной VM
Но не пугает зависимость VC от сториборда
Но не пугает зависимость VC от сториборда
В
Так у тебя тогда будет какой-то определённый VC
Д
ну да, тут тоже проперти viewModel является конечным конкретным типом, а не протоколом
В
А зачем указывать тип дженерика в сториборде? о_О
DK
DK
ну так надо указывать метод foo() который внутри вашего extension, а то получается foo как бы есть всегда, а extension который он дергает только если T: Printable
Д
А кто создает VC в случае верстки через сториборды? Класс сториборда и является фабрикой, ему нужен тип VM, чтобы зарезолвить
В
Понятно:
Хочешь 1 VC
У него вьюмодель под протоколом
А у протокола есть метод в экстеншоне, который никак не поддерживается протоколом.
Т.е. добавляешь какую-то свою логику, делая зависимость от конкретной реализации.
Но хочешь избежать зависимости от конкретной реализации.
Всё так?
Хочешь 1 VC
У него вьюмодель под протоколом
А у протокола есть метод в экстеншоне, который никак не поддерживается протоколом.
Т.е. добавляешь какую-то свою логику, делая зависимость от конкретной реализации.
Но хочешь избежать зависимости от конкретной реализации.
Всё так?