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

[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 значения енумов, в результате чего в собственных доработках приходилось раскапывать все эти места и править