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

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

Цитата:

Сообщение от 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

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

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

[S.Kuskov]

Цитата:

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

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

Контрпример. Программист создаёт продукт (например фреймворк классов или просто базовый класс) который не является конечным звеном в цепочке разработки. Такой программист должен предоставить удобный интерфейс для других программистов, которые будут использовать и поддерживать его разработки. Конечно можно все параметры запихнуть в один большой контейнер и сказать: хотите воспользоваться моим чудо классом - читайте документацию. При таком подходе безошибочно ввести все константы сможет разве что сам автор чудо-фреймворка, да и тот через неделю уже не вспомнит всех нюансов.

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

Цитата:

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

Контрпример. Программист создаёт продукт (например фреймворк классов или просто базовый класс) который не является конечным звеном в цепочке разработки. Такой программист должен предоставить удобный интерфейс для других программистов, которые будут использовать и поддерживать его разработки. Конечно можно все параметры запихнуть в один большой контейнер и сказать: хотите воспользоваться моим чудо классом - читайте документацию. При таком подходе безошибочно ввести все константы сможет разве что сам автор чудо-фреймворка, да и тот через неделю уже не вспомнит всех нюансов.

Какое отношение это все имеет к контролю типов и значений "параметров"?

Более того, Ваш пример вообще ни о чем, поскольку абсолютно тоже самое можно сказать о любом способе инициализации статических данных. Ну, например, создан вместо контейнера Struct, или MAP, или временная таблицы. И как Вы собираетесь угадывать "что есть что" в этом "чудо-хранилище"? Опираясь на имена? Или таки будете читать документацию?

Вот когда Вы создаете новую номерную серию, каким образом Вы определяете что надо заполнить в loadModulе()? Неужели из интерфейса все понятно?