Top-level code in packages

Brian Ripley stated that in the future it will not be a good idea to 
have top-level code in R packages other than assignments.  There is one 
important exception, though it leads instantly to an assignment.  To 
maintain compatibility across multiple platforms (R, S-Plus, and more 
than one version of each, Windows, Linux, etc.) I frequently use if( ) 
statements to conditionally define functions depending on the operating 
system and the version of R or S-Plus in effect.

On Fri, 2 Jul 2004, Frank E Harrell Jr wrote:

Brian Ripley stated that in the future it will not be a good idea to 
have top-level code in R packages other than assignments.  There is one 
important exception, though it leads instantly to an assignment.  To 
maintain compatibility across multiple platforms (R, S-Plus, and more 
than one version of each, Windows, Linux, etc.) I frequently use if( ) 
statements to conditionally define functions depending on the operating 
system and the version of R or S-Plus in effect.

That _is_ a top-level assignment. `Defining' a function is actually
assigning a value to a symbol, and code inside if, for, etc is executed at
top level.

I prefer to write

foo <- if(tools:::.OStype() == "windows") {...} else {...}

for conditional `definitions' precisely because it is clearer that is what 
is going on.

BTW, if you want to test the OS you can't do it with .Platform$OS.type and
allow cross-building, hence the test illustrated.

I use that sort of construct a lot, except that tools::: can't be used 
in general for backwards compatibility and for compatibility with 
S-Plus.  But often I use the following construct and would like to keep 
doing so, especially when defining functions for compatibility when the 
function only needs defining for a subset of the supported systems:

if(.R. || .SV4.) {  # variables defined in Hmisc or Design package
  foo <- function( . . . ) {
  }
  NULL   # prevents printing a result in S-Plus
}