LINUX.ORG.RU

как правильно передевать кучу ключевых аргументов?


0

0

Опять глупый вопрос. Есть, например, функция, которая вызывает несколько других функций, которые вызывают еще функции и т.д. И практически у каждой из них есть параметры, ключевые аргументы, которые должен задавать пользователь.
Как быть в такой ситуации? Передавать самой «верхней» функции тучу параметров, которые она должна раздать всем «дочерним» функциям, очень неудобно.
А как тогда быть? Надо же чтобы конечный пользователь не видел всех потрохов вызова вложенных функций, но чтобы как-то задавал их ключевые параметры.

★★

Ответ на: комментарий от mikki

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

bik ★★
() автор топика
Ответ на: комментарий от bik

Что значит без явного? Структуры, глобальные переменные.

mikki
()

То, что тебе нужно, называется «контекст». Самая главная функция инициализирует контекст должным образом и вниз спускает только его (указатель на него). Низлежащие функции смотрят в контексте на то, что им нужно.

mv ★★★★★
()
Ответ на: комментарий от mv

спасибо, похоже, это то, что нужно

bik ★★
() автор топика

заименованные параметры в виде хэша, или мапа.

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

siberean
()
Ответ на: комментарий от creepnee

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

anonymous
()
Ответ на: комментарий от bik

да, кстати, а вы имели в виду не продолжения (continuation)?

Нет.

mv ★★★★★
()
Ответ на: комментарий от anonymous

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

mikki
()
Ответ на: комментарий от korvin_

он имел в виду, например, динамические пепременные в CL.

Я имел в виду просто контекст :) Структура со всеми нужными переменными - контекст. Хэш со всеми нужными переменными - тоже контекст. Массив с параметрами тоже контекст. И вагон аргументов функций - это тоже он. ТС остаётся только понять, что код исполняется в каком-то контексте, и этот самый контекст можно организовать 101 способом. Будет лучше, если он представлен одним параметром, а не тыщей, и с ним легко работать.

mv ★★★★★
()
Ответ на: комментарий от bik

Тут монада Reader напрашивается сама собой :) А если серьезно, то используй структуры, записи или как они там называются в твоем языке.

dave ★★★★★
()
Ответ на: комментарий от dave

а ссылку можно на конкретный пример

bik ★★
() автор топика
Ответ на: комментарий от bik

Дьявол кроется в деталях, т.е. в синтаксическом сахаре. Просто вычисление в монаде Reader - это функция, которой передается некоторое окружение. В случае монады оно передается каждому этапу вычисления. Поэтому все твои функции, будучи закодированными в монаде, будут иметь доступ к параметру окружения (к твоей «куче ключевых аргументов»). Главное, чтобы закодированные таким способом твои функции были вовлечены в это самое монадическое вычисление. Механика очень простая, но писать это без синтаксического сахара замучаешься. Да, и пост был на половину шуточным. Писать в таком стиле на Си, к примеру, - это ССЗБ, да еще без GC. А детали по монаде Reader можешь узнать, взяв учебник по хаскелю.

dave ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.