Skip to content

[Bioc-devel] Importing classes into NAMESPACE

8 messages · Michael Lawrence, Thomas Sandmann, Gabriel Becker +2 more

#
Hi,

R 3.2 check results give this NOTE for my package ("prebs"):
granges_from_cdf: no visible global function definition for ?GRanges?
granges_from_cdf: no visible global function definition for ?Rle?
granges_from_cdf: no visible global function definition for ?IRanges?
perform_rpa: no visible global function definition for ?ExpressionSet?

I get this note for all the classes that I use in my package. Does it mean
that I incorrectly import classes into NAMESPACE file?

In the NAMESPACE file I have:

importClassesFrom(Biobase,ExpressionSet)

importClassesFrom(GenomicRanges,GRanges)

importClassesFrom(IRanges,IRanges)

importClassesFrom(S4Vectors,Rle)
Regards,
Karolis
#
On the surface, it sounds like you just need to import() the symbols for
those functions.

On Wed, Feb 25, 2015 at 3:00 AM, Karolis Uziela <
karolis.uziela at scilifelab.se> wrote:

            

  
  
#
Hi Karolis,

These classes have constructor functions of the same name as the class. For
example, the constructor function for GRanges is called GRanges().

If you use the constructors you need to import them separately, e.g.

importFrom GenomicRanges GRanges

Best,
Thomas
#
Karolis,

Do you really not need any of the methods for GRanges and ExpressionSet
objects? import(GenomicRanges) might be better, even though the package
isn't exactly small.

~G

On Wed, Feb 25, 2015 at 6:27 AM, Thomas Sandmann <sandmann.thomas at gene.com>
wrote:

  
    
#
Thank you for your help everyone! Importing constructors separately (as
Thomas suggested), has solved the problem.

@Gabe: I am not using any methods from Biobase, GenomicRanges
and S4Vectors. I am only using their constructors. Does it mean that I can
skip importing the classes and only import the constructors? Or did you
have something else in your mind?

I thought it is better to avoid importing whole packages, especially if
they are large. Or do you have some arguments, why I should do that?

Regards,
Karolis
On Wed, Feb 25, 2015 at 3:31 PM, Gabe Becker <becker.gabe at gene.com> wrote:

            

  
    
#
On Wed, Feb 25, 2015 at 9:02 AM, Karolis Uziela <
karolis.uziela at scilifelab.se> wrote:

            
So the code in your package never uses the objects, only returning them
directly to the user for their use? If so, I think that's actually a case
where Depends is called for, since that functionality is not useful to the
user if they don't have those classes and methods available.
I haven't seen timings that tell me that targeted importing is worth the
extra maintenance cost when methods move around between packages, functions
change names, etc. It's largely a preference thing AFAIK, but I like to
make sure I get everything I will need without worrying about when I do an
import, rather than needing to be sure of the exact subset of symbols I
want to use before hand. This, of course, is less compelling when you
really do only need one thing, but I don't find that to be particularly
common situation myself.

~G

  
    
#
On Wed, Feb 25, 2015 at 9:13 AM, Gabe Becker <becker.gabe at gene.com> wrote:

            
Have them listed in Depends, but still import in the NAMESPACE, of course.
If GenomicRanges forms the foundation of your package, then it's more
practical to import(GenomicRanges). If you're only cherry-picking a few key
functions from a package, then individual importFrom() declarations better
describe the specifics of that dependency.

  
  
1 day later
#
Hi Karolis,
On 02/25/2015 09:02 AM, Karolis Uziela wrote:
If you really don't do anything with the objects returned by the
GRanges(), Rle(), or IRanges() constructors, that is, you either return
them directly to the user or pass them as input to other functions (not
methods), and if you don't define yourself methods for these classes,
I think you can skip importing the classes. However, as Gabe pointed
out, the cherry-picking game is generally not worth it and will often
turn out to be counter-productive.

Cheers,
H.