On Fri, Oct 25, 2013 at 1:39 PM, John Chambers <j...@r-project.org> wrote:
> 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.
To clarify that last sentence for those not aware (and hopefully spare
someone having to troubleshoot this), executing R scripts/expressions
using 'Rscript' rather than 'R' differs by which packages are attached
by default. Example:
% Rscript -e "search()"
[1] ".GlobalEnv" "package:stats" "package:graphics"
[4] "package:grDevices" "package:utils" "package:datasets"
[7] "Autoloads" "package:base"
% R --quiet -e "search()"
> search()
[1] ".GlobalEnv" "package:stats" "package:graphics"
[4] "package:grDevices" "package:utils" "package:datasets"
[7] "package:methods" "Autoloads" "package:base"
Note how 'methods' is not attached when using Rscript. This is
explained in help("Rscript"), help("options"), and in 'R Installation
and Administration'.
/Henrik
>
> John
>
> On Oct 25, 2013, at 11:26 AM, Michael Lawrence <lawrence.mich...@gene.com>
> wrote:
>
>> On Wed, Oct 23, 2013 at 8:33 PM, Kasper Daniel Hansen <
>> kasperdanielhan...@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@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>
>> [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
