[Rd] advise on Depends

[John Chambers]

One additional point to Michael's summary:

The "methods" package itself should stay in Depends:, to be safe.

There are a number of function calls to the methods package that may be included in generated methods for user classes.  These have not been revised to work when the methods package is not attached, so importing the package only may run into problems.  This has been an issue, for example, in using Rscript.

John

On Oct 25, 2013, at 11:26 AM, Michael Lawrence <lawrence.michael at gene.com> wrote:

> On Wed, Oct 23, 2013 at 8:33 PM, Kasper Daniel Hansen <
> kasperdanielhansen at gmail.com> wrote:
> 
>> This is about the new note
>> 
>> Depends: includes the non-default packages:
>>  ‘BiocGenerics’ ‘Biobase’ ‘lattice’ ‘reshape’ ‘GenomicRanges’
>>  ‘Biostrings’ ‘bumphunter’
>> Adding so many packages to the search path is excessive and importing
>> selectively is preferable.
>> 
>> Let us say my package A either uses a class B (by producing an object that
>> has B embedded as a slot) from another package or provides a specific
>> method for a generic defined in another package (both examples using S4).
>> In both case my impression is that best practices is I ought to Depend on
>> such a package, so it is a available at run time to the user.
>> 
>> 
> For classes, you just need to import the class with importClassesFrom().
> For generics, as long as your package exports the method with
> exportMethods(), the generic will also be exported from your package,
> regardless of whether the defining package is attached. And the methods
> from the loaded-but-not-attached packages are available for the generic. So
> neither of these two is really a problem.
> 
> The rationale for Depends is that the user might always want to use
> functions defined by another package with objects consumed/produced by your
> package, such as generics for which your package has not defined any
> methods. For example, rtracklayer Depends on GenomicRanges, because it
> imports objects from files as GenomicRanges objects.  So just consider what
> the user sees when looking at your API. What's private, what's public?
> 
> Michael
> 
> 
>> Comments?
>> 
>> Best,
>> Kasper
>> 
>>        [[alternative HTML version deleted]]
>> 
>> 
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>> 
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel