Поиск переменной для присвоения происходит рекурсивно во всех родительских окружениях. Это может приводить к разным сложно отлаживаемым ситуациям.

Есть такой вопрос, как разумнее решить вопрос, я хочу что бы функция создавала n обьектов в global env процессе выполнения.  Например 10 соединений к разным БД.

И без использования <<- единственный вариант который я вижу, это в список их накидать

я в целом не уверен, что это хорошая практика, n разных открытых соединений
не лучше ли будет создать функцию с аргументом выбора бд и аргументом запроса, которая используется при запросе? то есть, открывает соединение, импортирует данные, закрывает соединение

А, ясно. Просто я использовал <<- когда надо было вывести Монте-Карло-распределение аргумента из функции, и всё было нормально

Что мешает создать пустое окружение без родителей и накидать туда через assign? Список, впрочем, тоже вариант.

Я могу заменить в исходном вопросе соединение на n моделей например ,

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

соотвествено я одной функцией создаю n коннектов, циклом перебираю запрос по базам. Одной функцией закрываю конект. На все дела от 3 строк кода, с произвольной оьработкой результата внутри цикла.

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

Лучше всё же так не делать, а передавать параметры подключения в функцию, которая выполняет запрос и там открывать и закрывать. Хоть сейчас почти везде добавили финализаторы коннектов, которые выполняются при запуске сборщика мусора и к фатальным последствиям это не приведеёт, но практика всё равно не очень хорошая.

ничего, но тогда видимо и в глобал можно накидать через assign. ? почему в отдельное окружение лучше?

Чтобы все сущности одного типа были в одном месте. Я стараюсь не загаживать глобальное окружение без резкой необходимости. Ещё и побочным эффектом из какой-то функции.

Ну то есть идея в том, что бы циклом перебирать не коннекты, а параметры? звучит разумно

Параметры можно положить в YAML/TOML/JSON и подгружать их по названию секции. Или же можно налепить файлы типа:

param=value

и подгружать их через readRenviron, которая импортнёт значения в качестве переменных окружения. Удобно для Postgres, т.к. libpq понимает переменные окружения с префиксом PG и параметры коннекта в коде в явном виде можно вообще не указывать.

давайте упростим. Хочу функцию , Которая мне возврашает N обьектов, например 5 моделей, от линейной регрессии до бустинга. Все в список пихать?

param=value

во, спасибо! то что нужно!

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

а на выходе n обьектов через цикл?

На выходе 1 объект.

список из n моделей?

Без контекста не очень понятно как лучше сделать и что именно нужно. Причём тут базы, модели...

Я придерживаюсь мнения, что функция (как процедура) должно делать что-то одно, но понятным образом. Усложнения можно городить, конечно, но на нижнем уровне должны быть функции, принимающие минимум параметров и возвращающие простые объекты.

вопрос один простой. Хочу функцию которая создаст N обьектов. Например на вход датасет, на выход - линейная регрессия, градиентный бустинг, случайный лес.

Вопрос, как мне без использования <<- получить эти обьекты в глобал энв.