История изменений

Тип должен быть контрактом, тип должен быть гарантией от использование неправильных значений. А по факту проверяется не то, что нужно пользователю, а то, что проще проверить. Нужно: «номер порта из правильного диапазона» или «корректный адрес», а проверяют «число» или «строка».

Какому еще «пользователю»? Тип проверят то, что описал в нём программист. Это инструмент для разработчика, чтобы структурировать кисель в чёткую архитектуру.

Покажете как? На случай если беседа примет оборот «а вот мы сделаем класс и в конструкторе всё проверим», сразу контртезис: а) это проверяется на этапе работы, т.е. в динамике; б) в случае позднего связывания мы узнаём какой метод вызываем только в процессе работы, снова динамика; в) а вот, что мы гарантированно не забудем сделать проверку, признаю, полезное свойство.

Смысл типа ровно в том, что после того как граница типа пройдена, дальнейшее гарантируется компилятором.

В условном «питоне» (или php, ruby, не важно) у тебя в любом месте, где написано def foo(ip_port), дальше придётся ставить assert, который проверяет что: 1) ip_port вообще число; 2) ip_port число в корректном диапазоне. И это всё равно никак не спасёт от того, что foo() вместо номера порта в рандомный момент времени получит сводку с прогнозом погоды под Хабаровском.

Аналогично и для случая ip_port = bar().

Если же у нас есть foo(ip_port: IpPort), то вызывающая сторона заведомо передаёт число в нужном диапазоне.

Точки, где IpPort создаётся и проверяется, чётко локализованы и могут быть малой кровью исследованы. Все места, где «случайное число из входных данных» трансформируется в однозначный IpPort могут быть изучены на предмет того, что программа корректно обрабатывает ошибку и возвращает информацию о ней пользователю.

Тип должен быть контрактом, тип должен быть гарантией от использование неправильных значений. А по факту проверяется не то, что нужно пользователю, а то, что проще проверить. Нужно: «номер порта из правильного диапазона» или «корректный адрес», а проверяют «число» или «строка».

Какому еще «пользователю»? Тип проверят то, что описал в нём программист. Это инструмент для разработчика, чтобы структурировать кисель в чёткую архитектуру.

Покажете как? На случай если беседа примет оборот «а вот мы сделаем класс и в конструкторе всё проверим», сразу контртезис: а) это проверяется на этапе работы, т.е. в динамике; б) в случае позднего связывания мы узнаём какой метод вызываем только в процессе работы, снова динамика; в) а вот, что мы гарантированно не забудем сделать проверку, признаю, полезное свойство.

Смысл типа ровно в том, что после того как граница типа пройдена, дальнейшее гарантируется компилятором.

В условном «питоне» (или php, ruby, не важно) у тебя в любом месте, где написано def foo(ip_port), дальше придётся ставить assert, который проверяет что: 1) ip_port вообще число; 2) ip_port число в корректном диапазоне. И это всё равно никак не спасёт от того, что foo() вместо номера порта в рандомный момент времени получит сводку с прогнозом погоды под Хабаровском.

Если же у нас есть foo(ip_port: IpPort), то вызывающая сторона заведомо передаёт число в нужном диапазоне.

Точки, где IpPort создаётся и проверяется, чётко локализованы и могут быть малой кровью исследованы. Все места, где «случайное число из входных данных» трансформируется в однозначный IpPort могут быть изучены на предмет того, что программа корректно обрабатывает ошибку и возвращает информацию о ней пользователю.

Тип должен быть контрактом, тип должен быть гарантией от использование неправильных значений. А по факту проверяется не то, что нужно пользователю, а то, что проще проверить. Нужно: «номер порта из правильного диапазона» или «корректный адрес», а проверяют «число» или «строка».

Какому еще «пользователю»? Тип проверят то, что описал в нём программист. Это инструмент для разработчика, чтобы структурировать кисель в чёткую архитектуру.

Покажете как? На случай если беседа примет оборот «а вот мы сделаем класс и в конструкторе всё проверим», сразу контртезис: а) это проверяется на этапе работы, т.е. в динамике; б) в случае позднего связывания мы узнаём какой метод вызываем только в процессе работы, снова динамика; в) а вот, что мы гарантированно не забудем сделать проверку, признаю, полезное свойство.

Смысл типа ровно в том, что после того как граница типа пройдена, дальнейшее гарантируется компилятором.

В условном «питоне» (или php, ruby, не важно) у тебя в любом месте, где написано def foo(ip_port), дальше придётся ставить идти assert, который проверяет что: 1) ip_port вообще число; 2) ip_port число в корректном диапазоне. И это всё равно никак не спасёт от того, что foo() вместо номера порта в рандомный момент времени получит сводку с прогнозом погоды под Хабаровском.

Если же у нас есть foo(ip_port: IpPort), то вызывающая сторона заведомо передаёт число в нужном диапазоне.

Точки, где IpPort создаётся и проверяется, чётко локализованы и могут быть малой кровью исследованы. Все места, где «случайное число из входных данных» трансформируется в однозначный IpPort могут быть изучены на предмет того, что программа корректно обрабатывает ошибку и возвращает информацию о ней пользователю.