reference types vs value types
Jan. 9th, 2013 10:14 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassОчередной раз посрались с артурегом за типизацию. Его огорчает существование 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>)
Артурег же упорно пытается превратить нормальную типизацию в ад жабаскрипта, минимизируя ограничения на хранимые значения. Но даже в этом случае можно оставить часть ограничений и гарантировать, что код не сломается и не будет вести себя непредсказуемо. Достаточно просто иметь представление о областях определения функций и ввести некие вменяемые правила поведения в случае, если значение выходит за область определения.
Я пытаюсь особо не айседствовать и прислушиваться к мнению людей, но в последнее время это разведение проблем на пустом месте от незнания простейших вещей начинает чрезвычайно раздражать.
Отказ использовать статическую типизацию хотя бы как способ рассуждения о коде (если язык не поддерживает ее явно в нужном объеме или это язык с динамической типизацией) мне не понятен в принципе, это примерно как добровольно отказатся от электричества, компьютеров, лекарств и пойти жить в землянки и жрать грязные корни.
Причем даже использование языков с динамической типизацией ничего не меняет - оно всего лишь перекладывает рассуждения о коде с компилятора-тайп-чекера на программиста и дает возможность описывать более сложные типы меньшим количеством кода.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-01-09 09:23 pm (UTC)no subject
Date: 2013-01-09 09:28 pm (UTC)no subject
Date: 2013-01-09 09:33 pm (UTC)Но таки да, сути не меняет. Вы не правы.
no subject
Date: 2013-01-09 09:32 pm (UTC)no subject
Date: 2013-01-09 09:32 pm (UTC)no subject
Date: 2013-01-09 09:35 pm (UTC)При этом считать нулл и ундефайнед полноценными типами мне лично странно.
no subject
Date: 2013-01-09 09:39 pm (UTC)var s = "asdsa"; var s = new String("asdsa") в чём разница?
так сколько в граммах? 4 - 5 - 6? а infinity это что?
no subject
Date: 2013-01-09 09:42 pm (UTC)Разница в том, что у первой s тип будет строка, а у второй s будет объект. Прикинь.
Кстати, в курсе, какой тип будет у null? хотя null это тип!
А инфинити как и нан это ЗНАЧЕНИЯ типа number.
Ты еще спроси что такое 0 1 2 и 3
no subject
Date: 2013-01-09 09:44 pm (UTC)no subject
Date: 2013-01-09 09:46 pm (UTC)А зачем тебе это нужно знать?
no subject
Date: 2013-01-10 05:59 am (UTC)no subject
Date: 2013-01-10 06:38 am (UTC)no subject
Date: 2013-01-10 06:39 am (UTC)no subject
Date: 2013-01-10 07:07 am (UTC)В обычных языках строка является субтипом объекта, а в js?
no subject
Date: 2013-01-10 07:11 am (UTC)no subject
Date: 2013-01-09 09:42 pm (UTC)no subject
Date: 2013-01-09 09:43 pm (UTC)no subject
Date: 2013-01-10 07:05 am (UTC)Это не странно, вместе с наследованием и совместимостью null с любыми ссылками - система типов получается весьма красивой.
no subject
Date: 2013-01-10 07:19 am (UTC)no subject
Date: 2013-01-10 07:28 am (UTC)no subject
Date: 2013-01-10 07:40 am (UTC)