[Bioc-devel] NAMESPACE issue, possibly related to AnnotationDbi

J.J.Goeman at lumc.nl J.J.Goeman at lumc.nl
Mon Dec 7 09:51:22 CET 2009

 Dear Seth and Martin,

Thank you very much for your explanation. So, what is happening is that
we have two functions

- as.list, the base function, from the base package and therefore always
in my namespace.
- as.list, the S4 generic based on the function above, in AnnotationDbi
which had been attached to the user workspace with require().

In the namespace hierarchy the function (in the namespace) takes
precedence over the generic (in the user workspace), resulting in R
stubbornly trying to apply the base function to an object from the
AnnotationDbi package, even though a method for that object is

I can see that this makes perfect sense from a namespace perspective,
but it is rather peculiar from an S4 classes perspective. Would it not
be sensible if generics would always override the base functions they
are based on?

Best regards,



> -----Original Message-----
> From: bioc-devel-bounces at stat.math.ethz.ch 
> [mailto:bioc-devel-bounces at stat.math.ethz.ch] On Behalf Of Seth Falcon
> Sent: 04 December 2009 20:35
> To: bioc-devel at stat.math.ethz.ch
> Subject: Re: [Bioc-devel] NAMESPACE issue, possibly related 
> to AnnotationDbi
> Hi Jelle,
> I think I have an explanation for you.  Prior to your change, 
> you had AnnotationDbi listed in the 'Imports' field of the 
> DESCRIPTION file for your globaltest package.  Listing a 
> package in Imports tells R that these packges are 
> dependencies, but does not actually cause these packages to 
> be imported into your package's name space.  For that you 
> have to add something to NAMESPACE.
> The addition you made is fine.  You can also do a wholesale import as:
>    import("AnnotationDbi")
> And then you should not need the more granular imports.  
> However, the granular imports where you import specific 
> symbols is generally a good practice since it avoids 
> unintentional name conflicts.  A change in a package you 
> import could introduce a symbol clash, but this will not be 
> an issue if you have imported the minimal set of symbols.
> Does that help?
> + seth
> --
> Seth Falcon
> Program in Computational Biology | Fred Hutchinson Cancer 
> Research Center
> _______________________________________________
> Bioc-devel at stat.math.ethz.ch mailing list 
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

More information about the Bioc-devel mailing list