идея?
Я его избегаю ещё со времён С++, но там были весомые причины - во первых, это ломало всю красоту ООП дизайна, так как вынимало информацию о нижележащих типах в тех местах, где эта информация должна быть скрыта. Во вторых, это было медленно и работало только когда у объекта был vtable.
И вот я вчера джуниору одному в код ревью написал "let's get rid of downcast here", он спрашивает "why?". И тут я задумался.
даункаст вреден не только потому что это связано с перфом, а потому что в колсайте возникает знание о конкретных типах где достаточно было бы знания о трейте
джуну нужно обьяснить что любая паника это минус. Если есть два варианта как сделать с паникой и без (без потери функциональности/прокидывания всего "наверх") то всегда стоит делать без
Вы предлагаете "проглатывать" ошибки? Достался мне как-то такой проект... Переделывал.
я предлагаю делать невалидные состояния непредставимыми в системе типов
можно почитать введение в http://lucacardelli.name/Papers/TypeSystems.pdf, в частности про trapped и untrapped errors и про static safety. существует иерархия ошибок, которая отображает выбор дизайна API: 1) static checks 2) trapped errors 3) untrapped errors делаем 1, если не получается или получается неудобно, делаем 2, если не получается или получается неудобно, делаем 3
Обсуждают сегодня