Задача от буриданова осла

[Игорь Столяров]

Привет всем !

Сразу предупреждаю - вопрос чисто теоретический …
Есть некая процедура, в которую для обработки нужно передавать параметры-значения.
Много параметров, штук 20-30 … Процедура вызывается многократно, в цикле …

Видится 2 способа решения задачи.

1. Не заморачиваться.
Просто объявить процедуру с этими параметрами и при вызове их туда передать.

2. Объявить тип данных GROUP,TYPE со списком этих параметров.
Перед вызовом процедуры присвоить элементам группы значения параметров,
а саму процедуру при вызове передать адрес CONST GROUP.

И собственно вопрос от сабжа: какой из вариантов эффективней и лучше ?

В первом - всё многообразие параметров записывается в стек,
во втором куча операций присваивания перед вызовом процедуры ...

Не могу выбрать.

[Дед Пахом]

Для меня удобнее иметь процедуру с одним параметром, чем с 30-ю (а где 30, там скоро будет 50).

[kreator]

Я тоже за второй вариант. Можно и очередь приспособить. Для универсальности. Я так делаю отчёты. Передаю в процедуру отчёта очередь. А очередь у меня универсальная, пока на 200 полей. Да её нужно сформировать перед вызовом процедуры. Чем-то надо жертвовать.

[Yufil]

1. Не знаю, как сейчас - в CW6 натыкался на ограничение количества параметров, поле параметров в APP было ограничено, где-то 20 параметров-и не больше...
2. Когда параметров ну очень много, часть из них оказывается не сильно нужной. Например, из 30 параметров пять содержательные, остальные должны иметь значения по умолчанию.

3. Когда параметров ну очень много, пропустить или перепутать порядок - раз плюнуть, так что Group (или даже класс) оно лучшее.

4. Когда меня замучили горестные размышления на эту тему, реализовал передачу параметров в строке с ключами
Call MyProcedure('X1=15,X2=30,Y1=500,Name=`Имя` ..... ) с парсингом списка параметров в очередь и анализом оной.
Кстати, так удобно передавать несколько параметров при вызове через Start. Естественно, в этом случае добавить новый параметр - без проблем...

5. Да, ещё у меня есть аддоны-плагины и всё такое, у них должен быть единый интерфейс, а дополнительные параметры могут быть и разными.

[vic7tar]

Есть некая процедура, в которую для обработки нужно передавать параметры-значения.
Много параметров, штук 20-30 … Процедура вызывается многократно, в цикле …

А этом цикле меняются кол-во параметров и их типы?

[PavelNK]

Я тоже столкнулся с такой же проблемой.
Вроде бы есть, но сходу не нашел, ограничение по кол-ву параметров.
Раньше точно было.
Я думаю, что вообще удобней и правильней оперировать классами, т.е. передавать не группу и не очередь, а класс.
Если для обработки понадобились дополнительные данные об объекте, то они там есть, не нужно ничего объявлять, менять.
Нужно только изменить обработку в самой процедуре.
Как правило, так делается во всех языках, во всех современных библиотеках.

[Губин Игорь]

группа

У передачи параметров в явном виде есть, при таком их количестве, имхо, только одно ЯВНОЕ преимущество - не забудешь везде прописать. Остальное только недостатки

[Игорь Столяров]

Спасибо ! Здесь вопрос конечно о ручном коде был …
Коллективный интернет-разум выбрал GROUP. Значит будет GROUP.

Заморочки среды разработки с параметрами - это отдельная весёлая тема.
Кому скучно - можно попробовать указать в поле Protoptype: (,,,)

[Губин Игорь]

Кому скучно - можно попробовать указать в поле Protoptype: (,,,)

RTFM



Ничего личного

[vic7tar]

Кому скучно - можно попробовать указать в поле Protoptype: (,,,)

И что должно появиться?

[Игорь Столяров]

И что должно появиться?

Robert Zaunere - топлес.

[Губин Игорь]

Robert Zaunere - топлес

Слишком либерально, на мой консервативный вкус

[Дед Пахом]

Вообще говоря, можно разбить входные параметры на логически связанные объекты и передавать в процедуру несколько групп. Например, Фамилия+Имя+Отчество+Д.Р. = PersonGroup, ИНН+Номер паспорта = DocGroup и т.д.

[Yufil]

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

[Игорь Столяров]

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

Это вот очень правильное замечание ! Но при одном условии: сначала думать, а потом делать.
А когда просят для ископаемой программы добавить в функцию расчёта воронки продаж ещё 15 показателей …