R help - Aug 2001 - Packages: What expressions are allowed outside/before .First.lib?

Sorry for this long message. The two first questions asks for general coding
standard when creating packages, the third one asks if the .R files are
concatenated in lexical order or not, the fourth question is a
"how-to"
question. All questions are related. If there is a reference where I can
read about this please tell me, because then I could repost a more
restricted set of questions.

Q1. When loading pakages, if exists, the .First.lib function will be called
in the end. Is it correct that it is only in .First.lib one should have
"executable" code? Is it also true that "outside"
.First.lib, only function
declarations and objects assignments such as '.conflicts.OK <- TRUE'
should
be used?

Q2. Is it considered ok to use attr() outside .First.lib? I would like set
an attribute 'modifiers' to all my functions as they are declared. I
have
tried it and it work. This is an example of how one of my generated package
files looks like:

  callMe0 <- function(x)
    cat("hey\n")
  attr(callMe0, "modifiers") <- c("private")

  callMe <- function(x)
    callMe0(x)
  attr(callMe, "modifiers") <- c("public")

I know that I could put the attr() assignments in the .First.lib function,
but since I/we write code in (many) separated .R files, which are
concatenated when the library is build, it would be doomed to miss one or
have one to many. So, is the above code considered to be alright? (The
'private' and 'public' attributes are used to "hide"
some of the functions
from the end user.)


Q3. After having used the attr() approach for a while, we wanted to add some
control of the assignment of 'modifiers'. I wrote a function
"modifiers<-"
that assert that the values are valid before setting the attribute. Now the
code would look like

  callMe0 <- function(x)
    cat("hey\n")
  modifiers(callMe0) <- c("private")

  callMe <- function(x)
    callMe0(x)
  modifiers(callMe) <- c("public")

I think this code is a little bit more readable, but bullet-proof in the
sence that unknown modifiers can not be set. But, by doing this I know I am
in deep water; to load this library I rely on the fact that
"modifiers<-" is
already declared. It looks like the library source file is created by
concatenation the .R files in lexical order and one can force the
declaration of "modifiers<-" to appear first by putting it in a
file called
"000.R" (zeros). However, I don't know if one can rely on this?!


Q4. What I really want to do is to declare "modifiers<-" in another
package,
lets call it, 'myrootlib', which all other libraries we write relies on.
Trying

  require(myrootlib)  # Declares "modifiers<-"

  callMe0 <- function(x)
    cat("hey\n")
  modifiers(callMe0) <- c("private")

  callMe <- function(x)
    callMe0(x)
  modifiers(callMe) <- c("public")

won't work! The reason for this seems to be that the package
'myrootlib' is
not loaded (evaluated) until afterwards. This brings up the issues asked in
Q1 and Q2. Is there another way to do it or do we have to go back to the
approaches explained in Q3, Q2 or even Q1?

Thank you so much!

Henrik Bengtsson

Lund University/UC Berkeley
hb at maths.lth.se

PS. Any questions I ever ask about [R] and possible improvements for it, is
to improve my (and hopefully others) understanding and never to complain. I
appreciate all the work done by all the contributors and testers. Thanks.
DS.

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

Follow up on my own message: I found autoload(), see under Q4 below:
> -----Original Message-----
> From: owner-r-help at stat.math.ethz.ch
> [mailto:owner-r-help at stat.math.ethz.ch]On Behalf Of Henrik Bengtsson
> Sent: Tuesday, August 07, 2001 11:21 AM
> To: r-help at stat.math.ethz.ch
> Subject: [R] Packages: What expressions are allowed outside/before
> .First.lib?
>
>
> Sorry for this long message. The two first questions asks for
> general coding
> standard when creating packages, the third one asks if the .R files are
> concatenated in lexical order or not, the fourth question is a
"how-to"
> question. All questions are related. If there is a reference where I can
> read about this please tell me, because then I could repost a more
> restricted set of questions.
>
> Q1. When loading pakages, if exists, the .First.lib function will
> be called
> in the end. Is it correct that it is only in .First.lib one should have
> "executable" code? Is it also true that "outside"
.First.lib,
> only function
> declarations and objects assignments such as '.conflicts.OK <-
> TRUE' should
> be used?
>
> Q2. Is it considered ok to use attr() outside .First.lib? I would like set
> an attribute 'modifiers' to all my functions as they are declared.
I have
> tried it and it work. This is an example of how one of my
> generated package
> files looks like:
>
>   callMe0 <- function(x)
>     cat("hey\n")
>   attr(callMe0, "modifiers") <- c("private")
>
>   callMe <- function(x)
>     callMe0(x)
>   attr(callMe, "modifiers") <- c("public")
>
> I know that I could put the attr() assignments in the .First.lib function,
> but since I/we write code in (many) separated .R files, which are
> concatenated when the library is build, it would be doomed to miss one or
> have one to many. So, is the above code considered to be alright? (The
> 'private' and 'public' attributes are used to
"hide" some of the functions
> from the end user.)
>
>
> Q3. After having used the attr() approach for a while, we wanted
> to add some
> control of the assignment of 'modifiers'. I wrote a function
"modifiers<-"
> that assert that the values are valid before setting the
> attribute. Now the
> code would look like
>
>   callMe0 <- function(x)
>     cat("hey\n")
>   modifiers(callMe0) <- c("private")
>
>   callMe <- function(x)
>     callMe0(x)
>   modifiers(callMe) <- c("public")
>
> I think this code is a little bit more readable, but bullet-proof in the
> sence that unknown modifiers can not be set. But, by doing this I
> know I am
> in deep water; to load this library I rely on the fact that
> "modifiers<-" is
> already declared. It looks like the library source file is created by
> concatenation the .R files in lexical order and one can force the
> declaration of "modifiers<-" to appear first by putting it in
a
> file called
> "000.R" (zeros). However, I don't know if one can rely on
this?!
>
>
> Q4. What I really want to do is to declare "modifiers<-" in
> another package,
> lets call it, 'myrootlib', which all other libraries we write
relies on.
> Trying
>
>   require(myrootlib)  # Declares "modifiers<-"
>
>   callMe0 <- function(x)
>     cat("hey\n")
>   modifiers(callMe0) <- c("private")
>
>   callMe <- function(x)
>     callMe0(x)
>   modifiers(callMe) <- c("public")
>
> won't work! The reason for this seems to be that the package
> 'myrootlib' is
> not loaded (evaluated) until afterwards. This brings up the
> issues asked in
> Q1 and Q2. Is there another way to do it or do we have to go back to the
> approaches explained in Q3, Q2 or even Q1?
>
Instead of 'require(myrootlib)' above, it looks like
'autoload("modifiers<-", "myrootlib")' would
work. Is this a correct way to
use autoload?
> Thank you so much!
>
> Henrik Bengtsson
>
> Lund University/UC Berkeley
> hb at maths.lth.se
>
> PS. Any questions I ever ask about [R] and possible improvements
> for it, is
> to improve my (and hopefully others) understanding and never to
> complain. I
> appreciate all the work done by all the contributors and testers. Thanks.
> DS.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

On Tue, 7 Aug 2001, Henrik Bengtsson wrote:

> 
> Q1. When loading pakages, if exists, the .First.lib function will be called
> in the end. Is it correct that it is only in .First.lib one should have
> "executable" code? Is it also true that "outside"
.First.lib, only function
> declarations and objects assignments such as '.conflicts.OK <-
TRUE' should
> be used?
I think it's fine to put any executable code in a package.  The RSMethods
package does do some computation at install-time. There's some discussion of
this and a mechanism to make it more efficient at
   http://developer.r-project.org/Install.html

> 
> Q3. After having used the attr() approach for a while, we wanted to add
some
> control of the assignment of 'modifiers'. I wrote a function
"modifiers<-"
> that assert that the values are valid before setting the attribute. Now the
> code would look like
> 
>   callMe0 <- function(x)
>     cat("hey\n")
>   modifiers(callMe0) <- c("private")
> 
>   callMe <- function(x)
>     callMe0(x)
>   modifiers(callMe) <- c("public")
> 
> I think this code is a little bit more readable, but bullet-proof in the
> sence that unknown modifiers can not be set. But, by doing this I know I am
> in deep water; to load this library I rely on the fact that
"modifiers<-" is
> already declared. It looks like the library source file is created by
> concatenation the .R files in lexical order and one can force the
> declaration of "modifiers<-" to appear first by putting it in
a file called
> "000.R" (zeros). However, I don't know if one can rely on
this?!
It is not AFAICS documented, so we are not committed to it.  It is a consequence
of the way Perl and/or the shell lists directories, so it is probably reliable.
It also is the reason that .First.lib is typically put in a file called zzz.R

A simple, if inelegant, work-around is to concatenate the files yourself.
 
  -thomas

Thomas Lumley			Asst. Professor, Biostatistics
tlumley at u.washington.edu	University of Washington, Seattle


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

On Tue, 7 Aug 2001, Henrik Bengtsson wrote:
> Follow up on my own message: I found autoload(), see under Q4 below:
> 
> >
> > Q4. What I really want to do is to declare "modifiers<-"
in
> > another package,
> > lets call it, 'myrootlib', which all other libraries we write
relies on.
> > Trying
> >
> >   require(myrootlib)  # Declares "modifiers<-"
> >
> >   callMe0 <- function(x)
> >     cat("hey\n")
> >   modifiers(callMe0) <- c("private")
> >
> >   callMe <- function(x)
> >     callMe0(x)
> >   modifiers(callMe) <- c("public")
> >
> > won't work! The reason for this seems to be that the package
> > 'myrootlib' is
> > not loaded (evaluated) until afterwards. This brings up the
> > issues asked in
> > Q1 and Q2. Is there another way to do it or do we have to go back to
the
> > approaches explained in Q3, Q2 or even Q1?
> >
> 
> Instead of 'require(myrootlib)' above, it looks like
> 'autoload("modifiers<-", "myrootlib")' would
work. Is this a correct way to
> use autoload?
> 
Well, it's valid.  

The current autoload() is really a proof-of-concept and might well get replaced
or removed by a more elegant mechanism at some point.  My guess is that the
order in which the files are concatenated may actually be more reliable than
autoload.

    -thomas

Thomas Lumley			Asst. Professor, Biostatistics
tlumley at u.washington.edu	University of Washington, Seattle


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._