|
Sgt.PepperЯ с Вами не совсем согласен, но это спор более мировоззренческий, чем айтишный.
Собственно, именно об этом я и говорил в шутке про сержанта :) Вопрос собственно в том, что "то ли стандарт вводится там, где действительно нужен", то ли "стандарт должен быть всегда, а отступления вводятся там, где действительно нужны". Если позволите, ещё один старый анекдот:
Немецкий фельдфебель взял отпуск и поехал на экскурсию в Париж. Остановился в гостинице, поужинал, поднялся к себе. Наступила ночь. От соседей слева раздалось:
- А-а, а-а.. Жан, любимый, помедленнее, не спеши так, а-а...
Чуть позже от соседей справа раздалось:
- А-а, Пьер, ну что же ты, быстрее, быстрее!, А-А!!
Фельдфебель в бешенстве вскочил, схватил стек, и, стуча поочерёдно в ту и другую стену:
- Все! Слушаю мою команду! Раз-два, раз-два, раз-два!!
Sgt.PepperИзвините, я уже Вам некоторое время назад говорил, что аналогии и аллегории должны иллюстрировать высказанный тезис, а не являться сами по себе основой доказательства чего-то,
Дык и иллюстрирую. Тезис о том, что люди, ездящие по разным дорогам, не особо нуждаются в общем стандарте, и попытка бездумно внести такой и требовать соблюдения "потому что стандарт" влечёт много минусов и мало плюсов.
Sgt.PepperВариант, ненужность которого должны доказать Вы, а не говорить, что "пока что серьезных примеров не приведено - это никому не нужно".
Я могу обосновать ненужность этого варианта, но меня совершенно не устраивает декларируемая Вами постановка вопроса. Мы обсуждаем равноправные вариации некоторой концепции, поэтому доказывать должны в равной степени. Кроме того, я очень прошу не перевирать мои слова: я говорю, что потребность именно в такой реализации крайне редка, и вносимые ей минусы и неудобства несравнимо перевешивают редкие полезные случаи.
А обосновывается, собственно, просто. У человека есть довольно чёткое интуитивное понимание понятия "значение введено / значение не введено", соответствующее is not null / is null. Скажем, для тех же чисел 0, 1, 2, 1.2e8, 238.85(342) - примеры введённых значений, пустота - значение не введено, null. Он с ними удобно и естественно оперирует, как программист так и пользователь. И глядя на поле ввода, где может стоять ноль, а может ничего не стоять, особенно наглядно видна демагогичность предложения отождествить 0 и null.
Для строковых значений действует ровно то же самое восприятие, "Иванов" - значение введено, "" - значение не введено. И да, любой нормальный человек - то есть не-программист - считает, что "Иванов " = "Иванов", а " " = "". Мы пишем программы для людей, они должны вести себя ожидаемым для пользователя образом. Поэтому, пока нет существенных оснований поступать иначе, следует выбирать концепции, соответствующие модели мира, ожиданиям пользователей.
Программист вполне может держать в голове концепцию "есть null (воспринимаемый пользователем как пустота), есть пустая строка (воспринимаемая пользователем опять же как пустота) и есть непустые строки". Но в 99.99% случаев ему просто незачем это делать, это только лишнее неудобство на пустом месте, проявляющееся каждый раз, когда программисту надо сконкатенировать это поле, сджойнить его или получить в него ввод из интерфейсной формы. Реальную потребность в этой концепции лучше всего показывает факт повсеместного отсутствия визуальных компонент, способных наглядно показать пользователю отличные null и пустую строку или дать пользователю выбрать между тем и другим. В тех редких случаях, когда такое требуется, программисты рожают что-нибудь вроде edit-а "Password" с чекбоксом "Password is blank".
Так вот: я утверждаю, что из двух концепций, одна из которых позволяет "один в один" реализовать почти все реальные потребности и с тривиальными доработками - оставшиеся, а другая - требует некоторой работы почти в каждом случае, первая лучше. Потому как при прочих равных делает работу проще, а её результат - качественнее.
Sgt.PepperТак почему бы не пойти по пути осмысленного выбора программистом?
Давайте рассмотрим ситуацию в общем виде. У нас есть несколько вариантов поведения системного объекта. Реализуя объект, мы можем:
1. Обязать явно указывать вариант в каждом месте использования объекта (те альтернативы, которые Вы привели)
2. Обязать явно указывать вариант в каждом месте создания объекта (то есть в create table кроме null / not null указывать отношение к пустым строкам)
3. Выбрать единственный вариант и заставить, когда он не подходит, делать явную доработку руками (как сейчас в Oracle).
Для каждого из этих подходов можно привести примеры, когда он оптимален. На пальцах.. третий вариант оптимален тогда, когда этот выбранный вариант нужен кардинально чаще других. Второй - оптимален по мощи, но предъявляет высокие требования к программисту, довольно легко внести ошибку. Первый - допустим тогда и только тогда, когда выбор преподносится в явном виде (например, как обязательный параметр функции) и оптимален, когда нет явно доминирующего выбора.
Так вот, "осмысленный выбор" в данном контексте не устраивает меня в первую очередь из-за нарушения требования "в явном виде".
Sgt.PepperНу возможно, придется Вам написать пару лишних символов по варианту 2 или 3, которые Вы бы не хотели писать, но зато сохранится возможность для других использовать в конкретном случае конкретный вариант, ... Неужели плата так велика?
Плата здесь - не лишние символы, это мелочь. Плата здесь - это внесённые ошибки. Я видел довольно много технологий, постулировавших "а вот здесь программист должен написать вот так", и, несмотря на все оргмеры, видел кучу ошибок, проистекающих из "программист забыл написать" или "написал не так".
Возвращаясь к примеру с пробелами - можно сделать технологию вроде "программист обязан писать trim() для каждого поля во всех хранимках, вставляющих или обновляющих информацию в таблицах". И гарантированно - будут отлавливаться ошибки. Люди не роботы. Такие вещи надёжны только когда они работают "без участия программиста в каждом конкретном случае".
Sgt.Pepperда и стандарты не нарушим.
Это стоит ещё меньше, чем лишние символы, имхо.
|
