Как правильно хранить статичный набор начальных данных в классах?

[Владимир Максимов]

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

Ну, например, разработчики Axapta может и хотели бы хранить данные о номерных сериях в виде контейнеров, но ведь использоваться-то они будут как записи таблицы. Так зачем же вводить промежуточные структуры, если в конце концов все-равно придется создавать записи? Ну, так сразу и создаем.

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

Кроме того, меня несколько удивляет акцентирование внимание на контроле типов данных. Это ты сам себе не доверяешь? Ну, в худшем случае, получишь ты ошибку не на этапе компиляции, а на этапе исполнения. Или написанный код предварительно не тестируется? А почему, собственно, надо контролировать только тип и не надо контролировать значение? Ведь тоже возможна ошибка!

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

[mazzy]

Цитата:

Сообщение от Владимир Максимов

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

предложи варианты

я говорил о наборе пар <таблица, поле> для редактирования query.
я предполагал что-то сугубо внутренне-программистское. такое что не дается пользователю.

Цитата:

Сообщение от Владимир Максимов

Это ты сам себе не доверяешь?

и сам себе не доверяю - особенно если буду добавлять/изменять что-нибудь через несколько месяцев.
и не доверяю другим программистам - которые будут добавлять/изменять что-нибудь после меня через некоторое время.

а главное - хочу иметь штатный механизм с контролем, который использовали бы другие, а я при добавлении/изменении не запорол бы их работу.

Цитата:

Сообщение от Владимир Максимов

Ну, в худшем случае, получишь ты ошибку не на этапе компиляции, а на этапе исполнения.

Хе... Это ж большая разница.

Цитата:

Сообщение от Владимир Максимов

Или написанный код предварительно не тестируется? А почему, собственно, надо контролировать только тип и не надо контролировать значение? Ведь тоже возможна ошибка!

А мне нравится эта вывернутая логика:
Конечно же надо контролировать значение - "скажи как".

И мне нравится этот переход на личности:
"раз у тебя код не тестируется, поэтому зачем тебе контроль начальных данных?"

==============
В контейнерах нет контроля ни типа, ни значения.
Я спрашивал - есть ли механизм который контролирует хотя бы тип?
Мне ответили - только создавать свои классы (но достаточно трудоемко)
Мало того, контейнер уж очень неповоротливая структура (хоть и легкая в использовании)

Но в стандартном коде повсеместно используются контейнеры.
А какого-то промежуточного/смешанного способа нет - либо контейнеры, либо классы

Цитата:

Сообщение от Владимир Максимов

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

[mayk]

Цитата:

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

Хе... Это ж большая разница.

Не смертельная. Учитывая удобство, можно и потерпеть. Особенно если не смешивать record'ы и int'ы в одном контейнере.

по теме: зависит от.
контейнеры,

container fields;;
fields = [[#CustAccount, custTable.custAccount],
[#CustId, custTable.accountNum],
etc];
for(i=1;i<=conlen(fields);++i){
 [bookmark, value]=conpeek(fields,i);
 excelDocument.insert(bookmark, value, #worksheet);

иногда hook'и (типа Runbase.dialogPostInit)

void initQuery(){;
   query = new Query(querystr(aotquery));
   postInitQuery(); //наследники могут делать грязную работу здесь, не перекрывая initQuery()

Особенно если предполагается что вызов super'а накладен:

void initQueries(){;
   for(i=1;i<N;++i)
   query = new Query(querystr(aotquery));
   this.postInitQuery(query); 
   this.addQuery(query);//здесь хук для инициализации легче сделать чем super() в DerivedClass.initQueries()

лучше всего вместе с parm'ами

myClass = myClass::construct(/**/);
myClass.parmQuery().dataSourceTable(xx).range(...);

List'ы и struct'ы на этапе компиляции всё равно не поймают ошибку типов. И вроде не на ембеддеде клиент запускается, чтобы сильно о памяти беспокоиться.

[Владимир Максимов]

Цитата:

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

я говорил о наборе пар <таблица, поле> для редактирования query.
я предполагал что-то сугубо внутренне-программистское. такое что не дается пользователю.

Как "стандартно" задается пара <таблица, поле> для будущего Range? Очевидно, через функции tablenum(), fieldnum(). И вот КАК здесь можно ошибиться? Приведи пример.

Это очень показательный пример того, что без знания цели, выбор "идеального" средства - бессмысленное занятие

Цитата:

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

А мне нравится эта вывернутая логика:
Конечно же надо контролировать значение - "скажи как".

Ну, это просто. Если известно, что речь идет о паре: таблица-поле, то, очевидно, можно проконтролировать корректность Id-таблица и корректность Id-поля. Только вот, не кажется ли, ну, мягко говоря, странным подобное занятие? Разве tablenum() и filednum() в принципе могут дать не корректное значение?

Цитата:

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

И мне нравится этот переход на личности:
"раз у тебя код не тестируется, поэтому зачем тебе контроль начальных данных?"

Это не "переход на личности". Это доведение до абсурда, чтобы показать не корректность исходной постановки задачи.

Ведь насколько я понимаю, Вы не ставите задачу проверки значения не потому, что это невозможно "в принципе". Как раз-таки очень даже возможно. Просто Вы понимаете полную бессмысленность этой задачи. Однако контроль типов Вам не кажется бессмысленным. Почему, собственно? Только потому, что это относительно просто?

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Как "стандартно" задается пара <таблица, поле> для будущего Range? Очевидно, через функции tablenum(), fieldnum(). И вот КАК здесь можно ошибиться? Приведи пример.

легко. здесь выкладывают проекты.
проекты могут быть импортированы в среду, где таких таблиц нет.

другой вариант: дев и продакт системы.
в дев таблицы и поля есть, а в продакт еще не перенесли.

или вот так: Несколько AOS: синхронность изменения объектов

Цитата:

Сообщение от Владимир Максимов

Это очень показательный пример того, что без знания цели, выбор "идеального" средства - бессмысленное занятие

Как скажете

Цитата:

Сообщение от Владимир Максимов

Ведь насколько я понимаю, Вы не ставите задачу проверки значения не потому, что это невозможно "в принципе". Как раз-таки очень даже возможно. Просто Вы понимаете полную бессмысленность этой задачи. Однако контроль типов Вам не кажется бессмысленным. Почему, собственно? Только потому, что это относительно просто?

[Evgeniy2020]

Я бы может генерил бы на основе таблиц и полей, или классов (метаданных)
XML формы для ввода, что то вроде ASP.net или веб сервис,
и не программист мог бы вводить данные с привязкой к метаданным (не по id а возможно символьно)

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

можно было бы сделать веб сервис поставщик данных, на основе того что вводят не программисты. в веб поля которые генерятся на основе дев метаданных.

[Владимир Максимов]

Цитата:

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

легко. здесь выкладывают проекты.
проекты могут быть импортированы в среду, где таких таблиц нет.

другой вариант: дев и продакт системы.
в дев таблицы и поля есть, а в продакт еще не перенесли.

или вот так: Несколько AOS: синхронность изменения объектов

Во всех описанных случаях при использовании tablenum() и fieldnum() будет ошибка на этапе компиляции. Импорт не получится. Нет причин в дополнительном контроле не только значений, но и типов данных.

Можно привести еще варианты, когда при вводе констант (статических данных) действительно необходим дополнительный контроль типов этих самых констант?

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Во всех описанных случаях при использовании tablenum() и fieldnum() будет ошибка на этапе компиляции. Импорт не получится. Нет причин в дополнительном контроле не только значений, но и типов данных.

вы так уперлись в функции tablenum и fieldnum.

Цитата:

Сообщение от Владимир Максимов

Можно привести еще варианты, когда при вводе констант (статических данных) действительно необходим дополнительный контроль типов этих самых констант?

конечно.
код цвета, тег html, шрифт, размеры шрифта, GUID, MAC-адрес, ip-адрес, адрес сайта в интернете, параметры границы, размеры окон по умолчанию, avi-файл отображения в progressBar, фигуры для тетриса, список начальных вопросов-ответов для Элизы, а также любые другие константы, например из аксаптовских макросов.

тысячи их.

Цитата:

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

Дисклаймер 2:
Специально возьму пример не из области учета, а из области программирования низкого уровня (чтобы не начинать обсуждение в стиле "сделай по-другому", "используй другой функционал").

[Владимир Максимов]

Цитата:

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

вы так уперлись в функции tablenum и fieldnum.

Да не в функции я уперся, а в то, что требование контроля самим же программистом введенных констант - бессмысленно.

Либо константы не являются константами в прямом смысле этого слова (tablenum() - это НЕ константа), либо никто и никогда не контролирует тип этих констант. В смысле, не пишет функционала по этому контролю

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

Цитата:

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

код цвета, тег html, шрифт, размеры шрифта, GUID, MAC-адрес, ip-адрес, адрес сайта в интернете, параметры границы, размеры окон по умолчанию, avi-файл отображения в progressBar, фигуры для тетриса, список начальных вопросов-ответов для Элизы, а также любые другие константы, например из аксаптовских макросов.

тысячи их.

Замечательно. А теперь приведите пример кода, где бы был прописан функционал контроля типа этих самых констант.

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

PS: Ну, считайте, я "прицепился" к фразе

Цитата:

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

минусы:
= никакой встроенной проверки типов. нужно писать самому
= никакой встроенной проверки количества данных. нужно писать самому

С моей точки зрения - это просто не нужно. Это не критерий оценки. Следовательно и не может быть поставлен как достоинство или недостаток того или иного метода

[Владимир Максимов]

Цитата:

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

предложи варианты

я говорил о наборе пар <таблица, поле> для редактирования query.
я предполагал что-то сугубо внутренне-программистское. такое что не дается пользователю.

Предлагаю

Для начала, небольшое отступление. Когда я начал программировать в среде X++ я считал "не правильным" создавать временные таблицы в AOT. Логика здесь была такая: данные временные, значит, и все объекты, которые их используют должны быть временными. В том смысле, что они должны быть удалены по окончании работы кода. А объект AOT остается! Т.е. "временный объект" оказывается "постоянным".

В настоящее время, я рассматриваю временные таблицы, как программный код написанный визуальными средствами. Это позволяет избавится от психологического "затыка".

Так вот, возвращаясь к задаче. Если сама задача заключается в создании/изменении query, то, почему-то вариант создания этого самого query напрямую в AOT не рассматривается в принципе. "По определению". Почему собственно? Думаю, по двум причинам:

1. Тот психологический "затык", который я описал чуть выше
2. В отличие от временной таблицы query можно создать программно

Итого, предлагаю вариант прямого создания Query в AOT. Со всеми предопределенными Range.

=============================================

Ну, хорошо, предположим, "ломка" настолько сильная и не преодолимая, что заставить себя создать объект в AOT - невозможно . Ладно. Тогда переходим к "программистским" трюкам

Как правило, для построения query создается отдельный метод класса вроде BuildQuery. И вот тут еще один интересный вопрос.

А зачем вообще надо предварительно "запихивать" поля в какое-то промежуточное хранилище, если можно прямо так и писать код создания с явным указанием имен полей? Ну, там

queryBuildDataSource.addRange(fieldnum(...))

Зачем здесь "лишние" посредники? Хотите модифицировать query в классах-наследниках? Да пожалуйста! Есть куча методов для этого - clearRange(), findRange() и т.п.

==============================

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

Это как-раз стандартный подход в Axapta.

===============================

Другими словами, все предложенные решения сводятся к тому, что просто не создается временное хранилище для статических данных. Статические данные сразу используются. Без промежуточных хранилищ

Вот именно про это я и говорил, что бессмысленно рассматривать подобную задачу "вообще". Нужна конкретная постановка задачи в смысле конечной цели использования статического набора.

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Так вот, возвращаясь к задаче. Если сама задача заключается в создании/изменении query, то...
...у нас стоит задача иметь возможность делать query с разными таблицами-источниками...

Владимир Максимов, вы тормоз.
Тема называется: Как правильно хранить статичный набор начальных данных в классах?

[S.Kuskov]

Цитата:

Сообщение от Владимир Максимов

А зачем вообще надо предварительно "запихивать" поля в какое-то промежуточное хранилище, если можно прямо так и писать код создания с явным указанием имен полей? Ну, там

queryBuildDataSource.addRange(fieldnum(...))

Зачем здесь "лишние" посредники? Хотите модифицировать query в классах-наследниках? Да пожалуйста! Есть куча методов для этого - clearRange(), findRange() и т.п.

Цитата:

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

Ок, например, Query не позволяет удалять Range. Поэтому, по-уму надо бы сначала провести оптимизацию range'й.

в общем, бывают случаи, когда совсем статический подход не работает.
но согласен - это очень хороший подход в большинстве случаев.

.

[Владимир Максимов]

Цитата:

Сообщение от Владимир Максимов

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

Цитата:

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

предложи варианты

Именно это я и делаю. Предлагаю варианты конкретных ситуаций, поскольку по прежнему считаю, что просто нет единого "правильного" способа хранения статических данных. Тот или иной вариант является прямым следствием конкретной задачи. Говорить "вообще" - это говорить "ни о чем"

Исходная постановка задачи после всех уточнений, замечаний, разных "но" и "если" выглядит довольно странно. Примерно так:

Необходимо обеспечить запись некой "матрицы" (таблицы) значений с возможностью их последующей модификации. При этом предполагается, что возможно абсолютно произвольное изменение любой характеристики этой матрицы. Может измениться количество строк, количество столбцов, типы и расположение отдельных элементов и т.д. и т.п.

И что здесь можно ответить? Да любой объект, который может хранить списки подходит для этого! Хоть обычные массивы. Другой вопрос, а подходит ли выбранное решение для конкретной ситуации?

Другими словми, в исходной постановке задача решения не имеет, поскольку сводится к перечню всех возможных инструментов Axapta. Нужно четко обозначить границы задачи. Для каких целей будет использован статический набор?

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Именно это я и делаю. Предлагаю варианты конкретных ситуаций, поскольку по прежнему считаю, что просто нет единого "правильного" способа хранения статических данных.

Ок. Понял.
На ваш взгляд:
1. В Аксапте нет универсального способа хранения статических данных
2. для Query лучше хранить сам query в AOT.

Владимир Максимов, я отключюсь в этой ветке от общения с вами. Извините.

Другие мнения/дополнения будут?