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> tfunction (x) UseMethod("t") with> t <- function(x){min(x)}R raises no objection and uses this new version happily enough, as in> t3function(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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
The ability of override functions in R is an important part of its
extensibility. We certainly don't want it disabled, and indeed the
packages may well be using it, unseen to you.
You *can* change the actual definitions of system functions, but you would
work hard to do it, and the changes would not be saved. Much more often
they are masked by functions higher in the search path, e.g. in the user's
workspace.
I think you need to be aware of (and make use of) the function
`conflicts'.
Description:
`conflicts' reports on objects that exist with the same name in
two or more places on the `search' path, usually because an object
in the global environment or a package is masking a system object
of the same name. This helps discover unintentional masking.
On Mon, 19 Feb 2001, John Aitchison wrote:
>
>
> 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
>
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
>
--
Brian D. Ripley, ripley at stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272860 (secr)
Oxford OX1 3TG, UK Fax: +44 1865 272595
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
> Hi .. another newbie question .. is it possible to "lock" a function > (or indeed any object), making it read-only until "unlocked"?I don't know. But your example and further questions point to another answer.> For example, should I inadvertently (or through sheer stupidity <g> ) > override the definition of t > > > t > function (x) > UseMethod("t")[much stuff deleted] The books "Modern Applied Statistics With S-Plus", and "S Programming", both by Venables and Ripley, give a very good treatment of this issue. The short (and probably slightly flawed, but good enough) answer is that if you can understand how a search path works in an operating system, you can understand this. Stuff you create is first on the search path. Next come the libraries you load, in the reverse order - the last library you loaded is the first searched (*after* the stuff you wrote yourself). The order of the search path is shown with the "search()" command. help(search). For this reason, it's a pretty good idea to name your own functions something distinctly yours: my.t or ja.t are not bad.> 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.Don't know. I've assumed not; I'm not used to that sort of luxury, so it never occured to me to look for it ;-). And it helps to remember the programmer's mantra - "if it won't let you do the stupid things, it won't let you do the clever things". Sometimes, masking is deliberate, and useful. Most of the conflict you're describing seems pretty well serviced by the convention of picking names carefully, and sometimes adding the package name or initials to functions in the case of common names. Cheers Jason -- Indigo Industrial Controls Ltd. 64-21-343-545 jasont at indigoindustrial.co.nz -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._