On 22/02/2010 9:49 PM, Ben wrote:
Hi all,

I'm hoping someone could tell me what best practices are as far as
keeping programs organized in R.  In most languages, I like to keep
things organized by writing small functions.  So, suppose I want to
write a function that would require helper functions or would just be
too big to write in one piece.  Below are three ways to do this:


################### Style 1 (C-style) ###############
Foo <- function(x) {
  ....
}
Foo.subf <- function(x, blah) {
  ....
}
Foo.subg <- function(x, bar) {
  ....
}

################### Style 2 (Lispish?) ##############
Foo <- function(x) {
  Subf <- function(blah) {
    ....
  }
  Subg <- function(bar) {
    ....
  }
  ....
}

################### Object-Oriented #################
Foo <- function(x) {
  Subf <- function(blah) {
    ....
  }
  Subg <- function(bar) {
    ....
  }
  Main <- function() {
    ....
  }
  return(list(subf=subf, subg=subg, foo=foo))
}
################### End examples ####################

Which of these ways is best?  Style 2 seems at first to be the most
natural in R, but I found there are some major drawbacks.  First, it
is hard to debug.  For instance, if I want to debug Subf, I need to
first "debug(Foo)" and then while Foo is debugging, type
"debug(Subf)".

You can use setBreakpoint to set a breakpoint in the nested functions, and it will exist in all invocations of Foo (which each create new instances of the nested functions). debug() is not the only debugging tool.

Another big limitation is that I can't write
test-cases (e.g. using RUnit) for Subf and Subg because they aren't
visible in any way at the global level.

For these reasons, style 1 seems to be better than style 2, if less
elegant.  However, style 1 can get awkward because any parameters
passed to the main function are not visible to the others.  In the
above case, the value of "x" must be passed to Foo.subf and Foo.subg
explicitly.  Also there is no enforcement of code isolation
(i.e. anyone can call Foo.subf).

Style 3 is more explicitly object oriented.  It has the advantage of
style 2 in that you don't need to pass x around, and the advantage of
style 1 in that you can still write tests and easily debug the
subfunctions.  However to actually call the main function you have to
type "Foo(x)$Main()" instead of "Foo(x)", or else write a wrapper
function for this.  Either way there is more typing.

So anyway, what is the best way to handle this?  R does not seem to
have a good way of managing namespaces or avoiding collisions, like a
module system or explicit object-orientation.

Packages are self-contained modules. You don't get collisions between names of locals between packages, and if they export the same name, other packages can explicitly select which export to use.

 How should we get
around this limitation?  I've looked at sample R code in the
distribution and elsewhere, but so far it's been pretty
disappointing---most people seem to write very long, hard to
understand functions.

I would normally use a mixture of styles 1 and 2. Use style 2 for functions that really do need access to Foo locals, and use style 1 for self-contained functions.

Duncan Murdoch

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to