BLUP: Каковы риски создания среды, родителем которой является .GlobalEnv, и вызова setRefClass в этой среде?
У меня есть пакет ( хранилище на Github ), который загружает содержимое R-файла, предоставленного HDFql. Эта оболочка содержит вызов setRefClass . Попробовав много разных вещей (большинство из которых потерпели неудачу), я остановился на поиске оболочки в среде, которая является потомком .GlobalEnv. Сама среда обитания находится в среде, содержащейся в упаковке. Это вложение было необходимо, чтобы обойти binding ошибок, потому что вызов setRefClass завершается ошибкой, если он выполняется внутри среды, предком которой является пространство имен пакета. Глобальная среда, казалось, была единственной средой, подходящей для оценки setRefClass.
Однако меня немного беспокоит создание и использование среды в пакете, родительским объектом которого является .GlobalEnv, и выполнение вызовов setRefClass внутри этой среды. Каковы потенциальные ловушки при этом? Существуют ли лучшие практики для удаления или «отмены» RefClass после завершения? Есть ли лучшее решение, о котором я не думаю?
Я включил ниже пример кода, хотя он не воспроизводим; если вам нужен воспроизводимый пример, вы можете клонировать репозиторий пакетов и / или установить его с devtools. Данный код находится в функции hql_load() в файле connect.r.
# "hql" is an empty environment exported by the package
constants = new.env(parent = .GlobalEnv)
source(constants.file, local = constants)
assign("constants", constants, envir = hql)
, где constants.file содержит код
hdfql_cursor_ <- setRefClass("hdfql_cursor_",
field = list(address = "numeric"),
method = list(
finalize = function(){
.Call("_hdfql_cursor_destroy", .self$address, PACKAGE = "HDFqlR")
}
)
)