[Rd] Multiple options for a package
Prof Brian Ripley
ripley at stats.ox.ac.uk
Tue Dec 14 14:30:19 CET 2004
I don't see why package options need have anything to do with options().
It seems to me that they really should be stored in the package namespace
(and so disappear when the package is detached). One package which does
this is 'sm' (although that has been ported from S-PLUS and is not the
cleanest R-only mechanism).
I also don't see why you need to save options to file _within a session_,
and the R testing framework does not do so -- take a look at what
massage-examples does. But if you do save options, remember that some are
read-only. I think you would find .readRDS and allies (see the help page)
more convenient.
On Tue, 14 Dec 2004, Eric Lecoutre wrote:
> Hi R-devel,
>
> I am facing a situation where the number of options I would like to propose
> to the user is somewhat big (and could easily increase more and more as I
> will code up a little more - even coming to a point where an user should be
> able to implement his own options).
>
> What we have to handle options is the couple:
> options(par=value) and getOption("par")
>
> I was aking myselft what would be the "better" strategy to handle a bunch of
> options for a package.
>
> I ended up with the idea of storing a list, as my options would also be
> classified, with something like:
>
> --
> MyPkgOptions =
> list(set1=list(par1=1,par2=2),set2=list(subset1=list(par1=11,par2=22),subset2=list(par1=111,par2=222)))
> options(PkgName=MyPkgOptions)
> --
>
> Then, to make easier the access to an element, I tweaked a little bit
> getOption, with the following version:
>
> --
> getOption <- function(x,...)
> {
> op = options(x)[[1]]
> if (length(list(...))>0) op <- op[[c(...)]]
> return(op)
> }
> --
>
> Making possible calls like:
>
> ---
> getOption("PkgName","set2","subset2","par1")
> [1] 111
> ---
>
> Then, I began to implement things like
> SetPkgOption(pkg,value=NULL,pathToValue) and getPkgOption(pkg,pathToValue)
>
> But I wonder if this wont be easier / more efficient at the C level. Sorry: I
> dont propose myself to make it, as my C skills are nearly null.
>
>
>
> To recap:
>
> - I need a way to set/get a lot of options for a package
> - I am ready to go on with my appraoch, delivering at the end some R
> functions
> - Seeing the way options() are handled with the internal call, I wonder if my
> idea is the better one
> - Specifically, I think someone with greater C skills should be able to set
> up functions like PkgOptions
> - I would like to hear about any other idea that would better suit me needs
>
> Best wishes,
>
> Eric
>
>
> PS: I think handling options at a package level would be a benefit for the
> user. Setting options would be done within .First or .onLoad when we know the
> package name. The options() tree would be far more readable, separating core
> options from others. Two weeks ago, i ended up with a list of 125 elements...
>
>
> PS2: an other related topic is Saving/Restore options. For my personal needs
> (testing within a session), I coded following functions:
>
>
> saveOptions <- function(file="R.options",...){
> opts=options(...)
> save(opts,file=file)
> }
>
> restoreOptions <- function(file="R.options"){
> bool=TRUE
> .tmp=new.env()
> if (!file.exists(file))
> {
> warning(paste("file ", file, " does not exist"))
> bool=FALSE
> }
> else
> {
> }
> load(file,.tmp)
> opts = get("opts",envir=.tmp)
> options(opts)
> return(bool)
> }
>
> Same scheme could be used for a set of options (say options for a package).
> Any comment on the above code?
>
> ______________________________________________
> R-devel at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
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 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
More information about the R-devel
mailing list