Cleaning up the workspace "hiding" objects

Question

It's getting to the point where I have about 100 or so personal functions that I use for line by line data analysis. I generally use f.<mnemonic> nomenclature for my functions, but I'm finding that they're starting to get in the way of my work. Is there any way to hide them from the workspace? Such that ls() doesn't show them, but I can still use them?

score 11 · Answer 1 · answered Apr 29 '11 at 01:44

11

If you have that many functions which you use on a repeated basis, consider putting them into a package. They can then live in their own namespace, which removes ls() clutter and also allows you to remove the f. prefix.

answered Apr 29 '11 at 01:44

Hong Ooi

56,353
13
134
187

+1 for a package. If you have this many functions that you are using over and over, they should have a home. Rolling a package is the proper "R way" to provide such a home. – Sharpie Apr 29 '11 at 02:53
yo, packagorama - it's too easy not to do, rather than hacky stuff like this – mdsumner Apr 29 '11 at 03:04
+1 I agree with you, but there is a cost associated with packaging... namely the time it takes to figure it out. It's on my R "List of things to Figure Out". – Brandon Bertelsen Apr 29 '11 at 03:37
+1 for the package initiative. That way, there's a better chance for you to document your functions which you will appreciate later in life. – Roman Luštrik Apr 29 '11 at 07:00
@Brandon read `?package.skeleton`. You can pass it a list of functions (their names, so reverse @DWin's answer to list only them) or provide a list of file paths of functions you want in the package. It does the hard work for you. You then need to write the documentation or at least edit the Rd files `package.skeleton()` creates. If you wanted you could create a single Rd file with an `\alias` for each function & remove the Rd files `package.skeleton()` created so the package can be installed. Then add Rd files for functions as you go along/get time. Packaging is easier than you think. – Gavin Simpson Apr 29 '11 at 11:04

score 5 · Answer 2 · answered Apr 29 '11 at 02:42

5

You can also put the function definitions into a separate environment, and then attach() that environment. (This is similar to Hong Ooi's suggestion, without the added step of making that into a loadable package.) I have this code in my .Rprofile file to set up some utility functions I commonly use:

local(env = my.fns, { # create a new env. all variables created below go into this env.
  foo <- function (bar) {
    # whatever foo does
  }

  # put as many function definitions here as you want

})

attach(my.fns)

All the functions inside my.fns are now available at the commandline, but the only thing that shows up in ls() is my.fns itself.

answered Apr 29 '11 at 02:42

Aaron

816
7
4

Thanks Aaron, attach(), I've read is almost as dangerous as it is useful. Do you use it alot? – Brandon Bertelsen Apr 29 '11 at 03:35
@Brandon, `attach()` is definitely dangerous when used with a `data.frame` -- it leads to inconsistent results, "surprises" when sharing code with others, etc. In a situation like this (where it is put in the `.Rprofile`, so executed consistently) I find it less likely to lead to problems. Of course, code that uses my customized functions can't be shared as easily with others, but that is more a problem of the nature of customized functions than of the use of `attach()` in this case. I don't use `attach()` in any other cases. – Aaron Apr 29 '11 at 04:07

IRTFM · Accepted Answer · 2011-04-28T23:06:23.197

4

Try this to leave out the "f-dots":

fless <- function() { ls(env=.GlobalEnv)[!grepl("^f\\.", ls(env=.GlobalEnv) )]}

The ls() function looks at objects in an environment. If you only used (as I initially did) :

fless <- function() ls()[!grepl("^f\\.", ls())]

You get ... nothing. Adding .GlobalEnv moves the focus for ls() out to the usual workspace. The indexing is pretty straightforward. You are just removing (with the ! operator) anything that starts with "f." and since the "." is a special character in regex expressions, you need to escape it, ... and since the "\" is also a special character, the escape needs to be doubled.

edited Apr 28 '11 at 23:06

answered Apr 28 '11 at 22:45

IRTFM

258,963
21
364
487

I like it, I just wish I understood what you did here. – Brandon Bertelsen Apr 28 '11 at 22:49
Bravo, thanks for the clarity! – Brandon Bertelsen Apr 28 '11 at 23:53
Additional question. Could this also work, with minimal changes to hide other objects that are not functions? Like vectors that I have to use frequently for exmaple? – Brandon Bertelsen Apr 29 '11 at 03:38
This did not depend at all on the type or mode of the objects. It only uses a pattern match on the name of the object. – IRTFM Apr 29 '11 at 04:13

score 3 · Answer 4 · answered Apr 29 '11 at 09:13

A couple of options not already mentioned are

objects with names beginning with . are not shown by ls() (by default; you can turn this on with argument all.names = TRUE in the ls() call), so you could rename everything to .f.<mnemonic> in the source files.
In a similar vein to @Aaron's answer but use sys.source() to to source directly into an environment.

An example using sys.source() is shown below:

env <- attach(NULL, name = "myenv")
sys.source(fnames, env)

where fnames is a list of file names/paths from which to read your functions.

Cleaning up the workspace "hiding" objects

4 Answers4