Продолжаем наш флешмоб #вечерний_опрос Кто ещё хотел бы рассказать?

Есть собственный пакет функций. Одна из этих функций должна запускать файл-скрипт и передавать в него параметры. Запуск должен быть в своем отдельном environment, в который отправятся также и спец-переменные (у Rmd это params, например). Сперва думал будет конструкция типа source(cur_path, local = new.env()), но она оказалась фуфлом по той причине, что из родительского env переходят все переменные, в т.ч. и технические. Это порождало ряд сложноуловимых косяков при отдельных кейсах на автотестах. Решение простое: rlang::new_environment(parent = .GlobalEnv) - создает то, что и требовалось - параллельный environment, в котором живет скрипт не задевая env функции-launcher-а

Если не хотите вникать в ООП есть пакет который делает каждый скрипт как функцию типа модуля в шайни https://wahani.github.io/modules/

Как-то знакомился с пакетом targets (он же ребенок drake), и там тоже были какие-то модули, параллелизм и т.п. Но по куче причин приходится всё-равно свой "типа-фреймворк" писать. Надо, например, организовать параллельное логирование, параметры интерактивно рисовать, кешировать, с конфигурациями работать, учитывать разность реальностей R и Rmd (getwd() пашет по разному), запускать из под командной строки оркестраторами и т.п. ООП - работал с ним в Python. Он там был не таким клиническим, как в джаве, но наследования, декораторы, вездесущее переобъявление одной и той же функции(метода?) 100500 раз - это да. Не в восторге. ООП вообще тема крайне специфическая. Гугл по теме "критика ООП" выдает массу аргументированных недостатков. Первая выдача: https://habr.com/ru/post/451982/ За modules спасибо, посмотрю. Работал с Shiny недавно, увидел там некие модули, но не добрался до их использования еще.

Кстати, немного поисследовал окружения функций. Мне почему-то казалось всегда, что environment функций располагается где-то параллельно с .GlobalEnv. Захожу в дебаггер самописной функции в ее environment, и вижу такое: # Окружение самой функции через дебагер environment() <environment: 0x55ee7e1a4300> # окружение обычного пакета R environment() %>% parent.env() <environment: namespace:test.r.utils.proj> # Чего? environment() %>% parent.env() %>% parent.env() <environment: 0x55ee7e040b80> attr(,"name") [1] "imports:test.r.utils.proj" # Объяснимо environment() %>% parent.env() %>% parent.env() %>% parent.env() <environment: namespace:base> # Приехали environment() %>% parent.env() %>% parent.env() %>% parent.env() %>% parent.env() <environment: R_GlobalEnv> # Неожиданный поворот!!! environment() %>% parent.env() %>% parent.env() %>% parent.env() %>% parent.env() %>% parent.env() <environment: package:test.r.utils.proj> attr(,"name") [1] "package:test.r.utils.proj" attr(,"path") [1] "/home/admin/00_projects/test.r.utils.proj/renv/library/R-4.1/x86_64-pc-linux-gnu/test.r.utils.proj" # А дальше идет очень длинная цепочка окружений каждого пакета environment() %>% parent.env() %>% parent.env() %>% parent.env() %>% parent.env() %>% parent.env() %>% parent.env() <environment: package:doRNG> attr(,"name") [1] "package:doRNG" attr(,"path") [1] "/home/renv-cache/v5/R-4.1/x86_64-pc-linux-gnu/doRNG/1.8.2/a32487a942bdf5fd34224ad46f786e67/doRNG" Очень забавно, и как-то не очень прозрачно

иерархия окружений - чуть ли не самая сложная часть языка https://textbook.rintro.ru/eval.html#eval-environment-hierarchy

Классная статья, спасибо!

это мой учебник и глава из него :) пожалуйста :)