On Wed, Feb 25, 2015 at 9:13 AM, Gabe Becker <becker.g...@gene.com> wrote:
> On Wed, Feb 25, 2015 at 9:02 AM, Karolis Uziela < > karolis.uzi...@scilifelab.se> 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? > > > > 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. > > Have them listed in Depends, but still import in the NAMESPACE, of course. > > > > 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? > > > > 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. > 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 > > > > > > Regards, > > Karolis > > > > On Wed, Feb 25, 2015 at 3:31 PM, Gabe Becker <becker.g...@gene.com> > wrote: > > > >> 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.tho...@gene.com> 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 > >>> > >>> [[alternative HTML version deleted]] > >>> > >>> _______________________________________________ > >>> Bioc-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel > >>> > >> > >> > >> > >> -- > >> Gabriel Becker, Ph.D > >> Computational Biologist > >> Genentech Research > >> > > > > > > > > -- > > > > Karolis Uziela > > > > PhD student > > Science for Life Laboratory > > Box 1031 > > 17121 Solna, Sweden > > Mob. +46 729 120 395 > > > > > > -- > Gabriel Becker, Ph.D > Computational Biologist > Genentech Research > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel