![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
reference types vs value types
Очередной раз посрались с артурегом за типизацию. Его огорчает существование value-types (или примитивных типов в жабе) из-за того, что они накладывают более жесткие ограничения на получение значений этих типов извне.
Например при загрузке из БД с полем, разрешающим null - придется либо сдыхать с исключением, либо устанавливать некое "значение-по-умолчанию", которое потом не отличишь от такого же значения, но введенного явно.
По моему - это какие-то проблемы, не то уровня начинающих, а вообще детсадовские, т.е. проблемы реально не существует.
Либо предметная область разрешает "отсутствие данных" и мы таскаем всюду Option[T] или жабьи объектные врапперы или C# Nullable<T>, либо предметная область разрешает использовать некое значение по умолчанию и нам его отличать от отсутствия данных не нужно, либо данные обязаны присутствовать и мы таскаем value-type, в базе делаем поле not null и в прочих протоколах делаем поле обязательным и дохнем с исключением (возвращаем код ошибки) при его отсутствии.
Если требования не зафиксированы заранее - пользуемся логикой и выбираем один из трех вышеописанных вариантов. Если требования в процессе разработки меняются - рефакторим. Если требования противоречивы - доводим до заинтересованных лиц и дальше либо делаем требования непротиворечивыми, либо ослабляем строгость ограничений (убираем not null и рефакторим все из value-types в reference-types или Option[T]/Nullable<T>)
Артурег же упорно пытается превратить нормальную типизацию в ад жабаскрипта, минимизируя ограничения на хранимые значения. Но даже в этом случае можно оставить часть ограничений и гарантировать, что код не сломается и не будет вести себя непредсказуемо. Достаточно просто иметь представление о областях определения функций и ввести некие вменяемые правила поведения в случае, если значение выходит за область определения.
Я пытаюсь особо не айседствовать и прислушиваться к мнению людей, но в последнее время это разведение проблем на пустом месте от незнания простейших вещей начинает чрезвычайно раздражать.
Отказ использовать статическую типизацию хотя бы как способ рассуждения о коде (если язык не поддерживает ее явно в нужном объеме или это язык с динамической типизацией) мне не понятен в принципе, это примерно как добровольно отказатся от электричества, компьютеров, лекарств и пойти жить в землянки и жрать грязные корни.
Причем даже использование языков с динамической типизацией ничего не меняет - оно всего лишь перекладывает рассуждения о коде с компилятора-тайп-чекера на программиста и дает возможность описывать более сложные типы меньшим количеством кода.
Например при загрузке из БД с полем, разрешающим null - придется либо сдыхать с исключением, либо устанавливать некое "значение-по-умолчанию", которое потом не отличишь от такого же значения, но введенного явно.
По моему - это какие-то проблемы, не то уровня начинающих, а вообще детсадовские, т.е. проблемы реально не существует.
Либо предметная область разрешает "отсутствие данных" и мы таскаем всюду Option[T] или жабьи объектные врапперы или C# Nullable<T>, либо предметная область разрешает использовать некое значение по умолчанию и нам его отличать от отсутствия данных не нужно, либо данные обязаны присутствовать и мы таскаем value-type, в базе делаем поле not null и в прочих протоколах делаем поле обязательным и дохнем с исключением (возвращаем код ошибки) при его отсутствии.
Если требования не зафиксированы заранее - пользуемся логикой и выбираем один из трех вышеописанных вариантов. Если требования в процессе разработки меняются - рефакторим. Если требования противоречивы - доводим до заинтересованных лиц и дальше либо делаем требования непротиворечивыми, либо ослабляем строгость ограничений (убираем not null и рефакторим все из value-types в reference-types или Option[T]/Nullable<T>)
Артурег же упорно пытается превратить нормальную типизацию в ад жабаскрипта, минимизируя ограничения на хранимые значения. Но даже в этом случае можно оставить часть ограничений и гарантировать, что код не сломается и не будет вести себя непредсказуемо. Достаточно просто иметь представление о областях определения функций и ввести некие вменяемые правила поведения в случае, если значение выходит за область определения.
Я пытаюсь особо не айседствовать и прислушиваться к мнению людей, но в последнее время это разведение проблем на пустом месте от незнания простейших вещей начинает чрезвычайно раздражать.
Отказ использовать статическую типизацию хотя бы как способ рассуждения о коде (если язык не поддерживает ее явно в нужном объеме или это язык с динамической типизацией) мне не понятен в принципе, это примерно как добровольно отказатся от электричества, компьютеров, лекарств и пойти жить в землянки и жрать грязные корни.
Причем даже использование языков с динамической типизацией ничего не меняет - оно всего лишь перекладывает рассуждения о коде с компилятора-тайп-чекера на программиста и дает возможность описывать более сложные типы меньшим количеством кода.
no subject
no subject
A fool with a too is still a fool. Жаба тут ни при чём. Хотя нет, немного виновата тем, что она настолько проста, что выловленный на улице рандомный индус может творить на ней говнокод через неделю подсматривания за коллегой.
no subject
no subject
no subject
no subject
no subject
да, бред какой-то произвели все вместе
no subject
no subject
no subject
no subject
no subject
Я например как-то сел и 2 дня потратил на тупейшее убирание ~80 копипаст кусков. Да, неприятно, да я постоянно матерился вполголоса, но мне за это и платят деньги. Не нравится проект -- так и скажите своему менеджеру, ищите другой. Если вы не раб, прикованный цепями к стене, найти обычно удаётся.
no subject
no subject
никогда
no subject
no subject
обтекай чмо
no subject