[R] "locking" functions

John Aitchison jaitchis at lisp.com.au
Mon Feb 19 09:22:55 CET 2001



Hi .. another newbie question .. is it possible to "lock" a function
(or indeed any object), making it read-only until "unlocked"?

For example, should I inadvertently (or through sheer stupidity <g> ) 
override the definition of t

> t
function (x) 
UseMethod("t")

with
> t <- function(x){min(x)}

R raises no objection and uses this new version happily enough, as in

> t3
function(x){min(x)}
> t<-t3
> fred <- function(z){ t(z) }
> x<-1:10; dim(x)<-c(2,5); x
     [,1] [,2] [,3] [,4] [,5]
[1,]    1    3    5    7    9
[2,]    2    4    6    8   10
> fred(x)
[1] 1

( I am guessing that I can still get at the original t somehow ? a sys 
function but I am not full bottle yet on environments and scoping)

Ending the session and saving the workspace works ok, 
and on restarting I get a message

Error in min(..., na.rm = na.rm) : invalid "mode" of argument

which is hopefully a clue that I have done something wrong, although it 
may not be immediately obvious just what..  

I am not sure of what is happening here .. R has loaded base by this time, 
presumably, and is comparing function headers in .Rdata with those in 
base?? or the other way around?


If I define a function (or any object) with a name which conflicts with 
that of an object in a package and I THEN load the package (or should I 
say library) with library(whatever) then .warn.conflicts kicks in and I 
get 
"
The following object(s) are masked _by_ .GlobalEnv :
"
so that is cool .. the problem (if you can describe it as such) comes with 
redefinition of a library function (and particularly base) AFTER the 
library is loaded. 

The t example above is obviously contrived and the need to override 
function and object definitions at will is understood, but I wonder if 
there is any language feature that can protect against accidental 
overrides. 

If not, is it worth considering an option for library? - in the spirit of 
warn.conflicts - say warn.redefinitions  ?? hmm, I guess the architectural 
implications would be significant, and it might be something that would 
need to be looked at at the class/object level. 

Perhaps a limited version of protection for builtins could be a start... 
there are ~ 1350 of them and it is a little hard to remember them all.


fwiw, thanks for any enlightment, and please no flames about me 
'suggesting' something that I am not willing to do myself.. working with 
the core of R would be way beyond my competence



oh, almost forgot

$platform
[1] "i386-pc-mingw32"
$arch
[1] "x86"
$os
[1] "Win32"
$system
[1] "x86, Win32"
$status
[1] ""
$major
[1] "1"
$minor
[1] "2.1"
$year
[1] "2001"
$month
[1] "01"
$day
[1] "15"
$language
[1] "R"

John Aitchison
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._



More information about the R-help mailing list