Пара простых вопросов юзающим PB12:

Правда ли, что константы, являющиеся полями пользовательского перечисления, могут быть только типа integer? Например, как здесь:


Прочитал это где-то в интернете, да с трудом верится.

И второй вопрос: здесь написано, что Custom Enumeration введены только в PB12.NET, но не в Классик ("With PB.Net, you now have the capability to define your own enumerations, and they behave exactly like the built-in system enumerations you already know and love..."). Так ли это? Тоже не очень верится.

Thanx!

1) Enumeration - это удобный (и к тому-же type safe!) способ хранения констант, когда константы одной группы ("семейства") хранятся в одном типе. Создаваемые нами в повседневной работе константы обычно служат для манипуляций с данными (кодами), извлечёнными из базы данных, и их типом данных часто служат не-числовые типы. Например, в оракловской аппликации, с которой я сейчас работаю, все статусы и коды - CHAR(1) и VARCHAR2 различных длин (т.е. нужны соответственно char и string в PB). Поэтому было бы естественным разрешить любой тип данных в качестве типа данных констант, входящих в enumeration (другое дело, что все константы перечисления должны принадлежать одному типу).

2) Спасибо за интересную ссылку - поиграюсь на работе!

Anatoly MoskovskyЯ знаю более удобный способ хранения констант - в константах.
Создать класс, в разделе инстанс переменных которого объявить константы нужного типа и значения.Это именно то, что пауэрбилдерщики делают уже много лет из-за неимения custom enumerations. Видимо, Вы называете этот способ удобным потому, что нам всегда кажется удобней то, что привычней.

Anatoly MoskovskyА потом в коде использовать нотацию ClassName.ConstNameВот из-за этого и рождаются порой уродцы вроде gnv_const.ORDER_STATUS_CLOSED вместо элегантного order_status.Closed! Конечно, можно для каждой группы констант создавать собственный NVO (я даже могу схавать то, что в PBL-ях будет больше классов), тогда код будет не менее элегантным, чем с перечислением (lnv_order_status.CLOSED), но вот проблему безопасности типов это никак не решает (кроме того, не встречал подобного подхода ни в одной аппликации - сейчас вот для интереса использовал его, жду code review).

Anatoly MoskovskyА type-safe - это вы выдаете желаемое за действительное, если при этом вам важно какое конкретно значение будет в константах перечисления, т.к. после приведения значения от типа перечисления к другому типу весь этот контроль типов накрывается медным тазом.Type safety существует чтоб уберечь разработчика от ошибок, а не чтоб стеречь кошелёк от грабителей. А обойти можно всё, что угодно (если так рассуждать, то и инкапсуляция - туфта, ведь можно пойти в потребляемый класс и изменить private и public). Просто если функция принимает в качестве параметра (или возвращает) статус заказа (хранимый в базе данных как строка), то я бы предпочёл иметь дело с типом order_status, а не string (ведь в последнем случае можно передать любые коды, а не только статусы заказа).

Ну и замечу, что для меня это отнюдь не вопрос из важных - так, балуюсь, экспериментирую.