[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