InventUpdate classes - общий вопрос по дизайну

[sukhanchik]

Цитата:

Сообщение от fed

Я когда-то тоже жалел, что статусы не были пронумерованы с шагом, скажем, 10 и приходиться вводить подстатусы в другом поле.
...
Что вы будете делать со всей логикой (а ее довольно много), которая местами пляшет не от сравнения статусов по < или >, а работает исключительно по равенству статуса константе ?
Я, в какой-то момент, решил что подстатусы заводить все-таки правильнее, и отсутствие промежуточных статусов - это не design flaw, а осмысленное решение..

Тут надо определиться. Либо надо ВЕЗДЕ делать сравнение по < > и тогда делать "дырки" в статусах, либо ВЕЗДЕ перечислять их и отказаться от < >. Я (мое личное мнение) за то, чтобы отказаться от < >, т.к. внутреннее числовое значение енума спрятано от пользователя/программиста. А если уж кто вводит новй статус - пусть 10 раз подумает в скольких местах это аукнется. Ту же новую складскую аналитику прописываем в N-цати местах - научились. Так и тут - научимся коль припрет

[S.Kuskov]

Цитата:

Сообщение от sukhanchik

внутреннее числовое значение енума спрятано от пользователя/программиста

Это почему же? Программисту вполне доступна информарция о числовых значениях enum'а. А если включить свойство UseEnumValue, то и пользователь будет иметь представление, если не о самих значениях, то хотябы о порядке их следования.

Т.е. в моём представлении, если UseEnumValue = NoYes::Yes, то enum представляет собой не просто множество доступных значений, а именно упорядоченное множество. И в таком случае логично повсеместно использовать операции < >.

[sukhanchik]

Цитата:

Сообщение от S.Kuskov

Это почему же? Программисту вполне доступна информарция о числовых значениях enum'а.

Не согласен. Пользуемся штатными средствами:
1. Обозреватель таблиц
2. Обычные формы, где используется енум
3. Отладчик.

Нигде не показывается числовое значение енума. Его можно увидеть лишь в свойствах енума аналогично его id. Т.е. конечно программист при желании может достать числовое значение. Но в коде он оперирует именно буквенными обозначениями енума, которые математически сравнивать некорректно на больше или меньше.

[S.Kuskov]

Согласен, что сравнивать значение enum'а непосредственно с числовым значением некорректно, но с другим значением этого же enum'а... почему нет? Я бы даже предложил сделать операции инкремента и декремента для таких упорядоченных enum'ов, которые бы переводили бы его в следующее или предыдущее состояние.

P.S.: Cоздавая relation'ы на таблицах с использованием enum приходится использовать их числовые значения.

[sukhanchik]

Цитата:

Сообщение от S.Kuskov

Согласен, что сравнивать значение enum'а непосредственно с числовым значением некорректно, но с другим значением этого же enum'а... почему нет? Я бы даже предложил сделать операции инкремента и декремента для таких упорядоченных enum'ов, которые бы переводили бы его в следующее или предыдущее состояние.

Вот... а в этом случае на уровне АОТа Enum-ы следовало бы разбить на 2 вида: Упорядоченные, для которых доступны операции инкремента/декремента и в которых программист не управляет значениями в БД, но зато сам может вставить промежуточный статус. Сейчас это не получится сделать, т.к. между двумя последовательными целыми числами новое число не вставишь. Хотя параметр UseEnumValue казалось бы мог решить сию проблему.

И неупорядоченные - в которых порядок неважен - главное - наличие значения (например, кодировка файла при экспорте).

Сейчас все имеющиеся Enum-ы неупорядоченные. Упорядочить их можно - сделав класс-обертку, который бы контролировал статусы и их сравнивал. Либо править ядро.
Поэтому, на будущее я и предложил - что хорошо было бы сделать однообразно. Неважно как.

Цитата:

Сообщение от S.Kuskov

P.S.: Cоздавая relation'ы на таблицах с использованием enum приходится использовать их числовые значения.

Увы, это так - но я бы назвал это скорее недостатком ядра, т.к. уже успел еще на 3.0 столкнуться с тем, что MS менял id значения енумов, в результате чего в собственных доработках приходилось раскапывать все эти места и править