LINUX.ORG.RU

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

Исправление Deleted, (текущая версия) :

позволили бы существенно сократить «проверяющий» код

Каким образом? Проверяющий код на входящие данные никуда не денется, иначе твоя идея не будет работать.

и оптмизировать выполнение за счёт того, что нам не пришлось бы создавать объект только ради того, чтобы убедиться в консистентности значения.

Куда ты собрался класть проверенное значение, если «объект» не создаётся?

Оптимальным видится такой вариант использования: переменная, заполняемая из внешнего источника -> наложение constraint'ов -> внутренняя переменная с мета-тегом «пройдён constraint такой-то».

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

Речь о том, что сами по себе типы данных в компилируемых языках - это сказка о повышении производительности, но никак не о повышении стабильности кода. Потому что если в вашу переменную типа UInt8, которая не может быть за диапазоном [101..143] приехало вдруг 235, а вы это не проверили в рантайме - ну как бы тип данных вас точно не спасёт.

Твоя идея описывает то же самое: проверку значений в рантайме. Я не понимаю что именно она меняет.

В общем, я же правильно понимаю, что везде подобные вещи реализованы сбоку, а не как встроенное средство самого ЯП?

Как ты предлагаешь это встроить в язык? А если я захочу встроенную в язык проверку, что в строке - имя поняши, то что мне делаеть? Повторю: в нормальных языках то, что ты хочешь, делается при помощи системы типов или какого-нибудь другого встроенного абстрактного механизма.

Исходная версия Deleted, :

позволили бы существенно сократить «проверяющий» код

Каким образом? Проверяющий код на входящие данные никуда не денется, иначе твоя идея не будет работать.

и оптмизировать выполнение за счёт того, что нам не пришлось бы создавать объект только ради того, чтобы убедиться в консистентности значения.

Куда ты собрался класть проверенное значение, если «объект» не создаётся?

Оптимальным видится такой вариант использования: переменная, заполняемая из внешнего источника -> наложение constraint'ов -> внутренняя переменная с мета-тегом «пройдён constraint такой-то».

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

Речь о том, что сами по себе типы данных в компилируемых языках - это сказка о повышении производительности, но никак не о повышении стабильности кода. Потому что если в вашу переменную типа UInt8, которая не может быть за диапазоном [101..143] приехало вдруг 235, а вы это не проверили в рантайме - ну как бы тип данных вас точно не спасёт.

Твоя идея описывает то же самое: проверку значений в рантайме. Я не понимаю что именно она меняет.

В общем, я же правильно понимаю, что везде подобные вещи реализованы сбоку, а не как встроенное средство самого ЯП?

Как ты предлагаешь это встроить в язык? А если я захочу встроенную в язык проверку, что в строке - имя поняши, то что мне делаеть? Повторю: в нормальных языках то, что ты хочешь, делается при помощи системы типов.