Skip to content

[Bioc-devel] NAMESPACE questions

4 messages · Diego Díez Ruiz, Seth Falcon

Original
Seth Falcon
# 
Hi Diego,

I'm cc'ing bioc-devel because I think others may find interest in
answers to your questions.  The good stuff is at the bottom.
On 18 Nov 2005, ddiez at iib.uam.es wrote:
Oops.  The best place for updated developer info is the Developer
Wiki:
http://www.bioconductor.org/developers/devwiki

We'll restore that URL, however, thanks for the report.
Some of these names seem strange:

Codelink-class especially because this is not a valid name unless it
is quoted.  I would suggest renaming.

The dots in the names can cause confusion because that is how S3
method dispatch works.
So one thing to try is simply R CMD INSTALL <YOURPACKAGE> before
running check.
Well the examples are supposed to illustrate how to use the public API
of your package.  That is, the part that end users will interact
with.  Hence, when running examples, only those functions that are
exported in the NAMESPACE file will be accessible.  Make sense?
Yes, exactly.  And since you loaded codelink last, I believe that an
unqualified call to normalize() would get the function defined in
codelink.  Names are resolved by looking in the environments defined
by the search path which you can inspect using search().  

If packges A and B both define a function foo (whether or not they use
a NAMESPACE) and if A appears before B in the search list as reported
by search(), then a call to foo() will get the definition in package
A.
At the interactive level, using "::" to fully qualify your function
calls is the best way to get the function you want.  The comment in
the documentation is about what to do inside your own package code.
Before I say a bit more on that...

Continuing with the packages A and B both defining foo(), let's
suppose that package A has a function bar that calls foo:

Package A                   
                            
bar <- function(x) {        
  ## stuff                  
  z <- foo(x*2)             
  z                         
}                           

Now suppose that package B comes first on the search path.  Without
NAMESPACES, when we call packge A's bar() function, it will end up
calling package B's foo and this is bad.

NAMESPACES protect us from this type of situation.  With a NAMESPACE,
package A can be sure that the foo it gets is its own regardless of
what the search path looks like.

If in package A we wanted to call function baz from package B then we
could:

- use B::baz()
- import baz from B in the NAMESPACE file and just call baz()

Either method will guarantee that we get the right baz.

Hope that clarifies some things with NAMESPACES.  If there are
questions, post 'em to the list and we'll do our best to clarify
further.

Best,

+ seth
2 days later
Diego Díez Ruiz
# 
Hi Seth,

El 18/11/2005, a las 18:03, Seth Falcon escribi?:
Than you for this tips. I have changed all names and let only with  
dots real S3 methods.
It really make sense.
This is only possible if package B has a NAMESPACE, isn't it?

And what if package A and B have either function foo() and B call  
also function foo() from package A. I defined a function log2 to  
manage log2 for some type of data and inside uses log2 from base  
package. But instead of that it tries to use log2 from my package.  
This is because my log2 if first in the search path. I could solve  
this using base::log2 in case log2 has a NAMESPACE but I prefer to  
rename my function. But developers deal normally in this situations?
Another question is that I have some S4 classes and methods. I make  
the corresponding entry in the NAMESPACE file but the documentation  
tell something about .onLoad call that must be present. I see that in  
package Biobase is in file zzz.R in R directory but I don't known how  
to call it in my case. In fact it is not actually and my package  
compiles and works without warning.

By the way I think it really clarifies things. I have solved the  
issues with my package and now has a  working NAMESPACE file (maeby  
with some bugs?)

Best,

D.
------------------------------------------------------
Diego D?ez Ruiz
Molecular Endocrinology.
Instituto de Investigaciones Biom?dicas
CSIC/UAM
Madrid (SPAIN)
mail:    ddiez at iib.uam.es
url:       http://www.iib.uam.es/~ddiez
tlf:         +0034915854446
fax:       +0034915854401
Seth Falcon
#
On 21 Nov 2005, ddiez at iib.uam.es wrote:
Yes, that is correct.  You cannot use the import directive in a
NAMESPACE file for a package that does not have its own NAMESPACE
file.  In such a case you can:

 a) write the the package maintainer and ask them to add a name space?
    ;-)

 b) Add the package to the Depends field in DESCRIPTION and live
    without the protection a name space provides.
Yes, both are good solutions.  In general, one should think carefully
before creating a function with the same name as a basic math function
in base.  There are times when this may be reasonable, but realize
that an end user who loads up your package (even with NAMESPACE) will
have a strange experience with log2.
First, you don't call .onLoad yourself.  All you do is define it.  The
.onLoad function is a "hook" function.  When your package is loaded, R
will look for a .onLoad function in your package.  If found, it will
be called.

As to whether or not you need one, I'm not sure.  It is true that the
Extension Manual says to include a .onLoad function that does
require(methods) if your package has S4 classes and a NAMESPACE.
However, I *suspect* this is no longer needed as long as you have
methods in Depends.
Excellent.  Thanks for asking some good questions.  I hope others will
find the discussion useful as well.

Best,

+ seth
1 day later