Expected or unexpected behavior? Use() with alias attaches more namespaces than specified

[SaintRod]

Hello, again!

Recently I noticed that using an alias resulted in importing more than was specified in the brackets, but not an using alias only imported what was specified. I didn't want to open an issue if this is expected behavior and I misunderstood the documentation.

Q: Is this behavior in example 2 expected?

Example 1: without alias

# not using alias imports specified functions
box::use(
  purrr[chuck],
  dplyr[select, filter]
)
chuck(letters, 1) # works
pluck(letters, 1) # fails

select(mtcars, carb) # works
summarize(mtcars, mean = mean(mpg)) # fails

Example 2: with alias

# using alias imports more than requested
box::use(
  purrr = purrr[chuck],
  dplyr = dplyr[select, filter],
  foo = astsa[acf1, acf2]
)

object.size(purrr) # 3256 bytes
length(names(purrr)) # 189
purrr$pluck(letters, 1) # works, but should it work?

object.size(dplyr) # 3384 bytes
length(names(dplyr)) # 298
dplyr$summarise(mtcars, mean = mean(mpg)) # works, but should it work?

object.size(foo) # 3384 bytes
length(names(foo)) # 119

output from session.info() before calling box::use() - raw state

R version 4.3.3 (2024-02-29 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19045)

Matrix products: default


locale:
[1] LC_COLLATE=English_United States.utf8  LC_CTYPE=English_United States.utf8    LC_MONETARY=English_United States.utf8
[4] LC_NUMERIC=C                           LC_TIME=English_United States.utf8    

time zone: America/Chicago
tzcode source: internal

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
[1] compiler_4.3.3 tools_4.3.3   

[klmr]

Yes, this is intentional, and explicitly documented behaviour: the stuff in square brackets is the attach specification; it controls what names are attached, not what names are present inside the module alias (and restricting that list wouldn’t be useful anyway).

However, there’s some lax wording in the documentation that might be misleading, I will change that:

 The list can also contain the special symbol ..., which causes all
-exported names of the module/package to be imported.
+exported names of the module/package to be attached.

---

(Note that object.size() returns nothing useful for environments: the numbers you are getting don’t correspond to the number of names inside the environment, nor their object sizes. Instead, they reflect the number and size of the attributes of the environment — i.e. their meta-information such as module name and path.)

[SaintRod]

Thank you @klmr

Will you please clarify how the attach specification and alias work together? Specifically, what is the difference between "attached" and "present inside the module alias"?

For example, using box::use() without an alias seems to only attach what's specified by the attach specification. Calling a function not specified in the attach specification doesn't work.

box::use(
  purrr[chuck]
)
chuck(letters, 1) # works, result = "a"

pluck(letters, 1) # fails: result = Error in pluck(letters, 1) : could not find function "pluck"

However, as you mentioned, "the attach specification ... controls what names are attached, not what names are present inside the module alias". The implication is that names not specified in the attach specification are available via alias$. If a name is present in the module alias but not in the attach specification should it be available to call?

In the example below, I want to attach chuck() from purrr and use the alias foo. As expected from your comments there are other names present in the alias, such as pluck.

Although other names are present, my confusion is that I expect only the chuck function to work since it's the only name specified in the attach specification. However, as can be seen below the pluck function also works.

box::use(
  foo = purrr[chuck]
)
foo$chuck(letters, 1) # works, result = "a"

foo$pluck(letters, 1) # works, result = "a"

If being able to use a function not specified in the attach specification is expected behavior, then what's the difference between foo = purrr[chuck] vs foo = purrr[...]?

[klmr]

“attach” in the context of ‘box’ means the same as it does in R generally. That is: make a name available in the current scope directly, without the need to explicitly qualify their package/module name.

If being able to use a function not specified in the attach specification is expected behavior, then what's the difference between foo = purrr[chuck] vs foo = purrr[...]?

The difference is that the first one only attaches chuck(), the second attaches all exports of the ‘purrr’ package:

box::use(foo = purrr[chuck])
pluck(letters, 1L)  # fails

box::use(foo = purrr[...])
pluck(letters, 1L)  # succeeds

In fact, the presence of the module alias (foo =) is unrelated to the question of what names are attached; it merely provides an additional way of accessing the imported names. This makes sense when you want to avoid a name conflict (e.g. between stats::filter() and dplyr::filter()) but you still want the simplicity of accessing non-conflicting names without having to explicitly qualify their module name every time. That’s why it is intentional that you can access all names of the import via foo$.

[SaintRod]

@klmr thank you very much for taking the time to respond.

I understand my confusion now! I mistakenly thought that when using an alias one had to use alias$ to call a function. I did not realize that as you show above one could call a function without qualifying the call via the alias. If I only need what's specified in the attach specification I won't use an alias, and then only those functions will be attached. I'll save time by not qualifying everything all the time :) I realize now I've been over-using aliases.

This thread was most helpful. Thank you again.