Обновить

Комментарии 2

Не могу поставить плюс, поэтому ловите виртуальный) Спасибо, отличный разбор!
Вопросик:
В статье упоминаются подклассы, но не затрагивается тема sealed-иерархий. Как, по-вашему, этот линт будет (или должен) взаимодействовать с exhaustive_cases? Кажется, что связка switch_on_type (как толчок к переходу на паттерны) и exhaustive_cases (для sealed) — это и есть та "золотая середина" для безопасной работы с типами, к которой нас подталкивает язык. Не упускаем ли мы здесь более крупную картину, фокусируясь только на runtimeType?

Я бы посоветовал всем, кто будет рефакторить свой код под switch_on_type, не просто механически менять синтаксис. Стоит сразу оценить, не является ли вся эта иерархия классов-кандидатом на sealed-модификатор. Зачастую это решает проблему на более глубоком, архитектурном уровне, а не просто "лечит" линтер.

Я люблю делать switch по типу даже с одной веткой, где if хватило бы. Чтобы был зелёный diff, если потом придётся обработать ещё один тип. Поэтому мне актуально даже без sealed.

Этот линт никак не взаимодействует с exhaustive_cases. Не должен и не будет.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации