On Feb 11, 2014, at 1:28 PM, Martin Morgan <mtmor...@fhcrc.org> wrote:
> On 02/11/2014 09:06 AM, Winston Chang wrote: >> To state the issue that Kirill raised in a different way... A package >> with S4 or reference classes and Depends:methods can throw an error >> when you do something as simple as this: >> Rscript -e "mypackage::foo()" >> >> But this will work: >> Rscript -e "library(mypackage); foo()" >> >> This is because when mypackage has Depends:methods, calling >> mypackage::foo() merely loads mypackage, and doesn't attach it -- and >> when this happens, the methods package is also loaded and not >> attached. In this situation, you can get errors of the type that Dirk >> noted. >> >> In contrast, library(mypackage) causes methods to be attached, and so >> you won't get those errors. This seems like a problem with the >> behavior of the :: operator. Why should it be that when a package is >> loaded, the packages listed in Depends are not attached? Because the whole point is that you don't want mypackage on the search path, otherwise you wouldn't use :: in the first place. Namespaces are about solving the namespace clutter, not exacerbating it ;). >> Presumably, >> when someone lists a package in Depends instead of Imports, it's for a >> good reason, as is the case here with the methods package. > > To me it's worth distinguishing between the particular problem associated > with the methods package, and the more general problem encountered when PkgA > fails to import symbols used in PkgB, and instead relies on PkgB symbols to > be found on the search path. In the latter it seems better practice to > import(PkgB) (or importFrom) in the NAMESPACE and probably Import: PkgB in > DESCRIPTION. > >> In the following thread, it's stated that the defensive approach is to >> use Depends:methods -- but that's still not enough for running the >> code listed above. >> http://r.789695.n4.nabble.com/advise-on-Depends-td4678930.html > > A more defensive defensive approach might be to add > > .onLoad <- function(...) require(methods) > But that will attach methods again - not good. I suspect the problem could be classified as bug in methods which doesn't behave correctly if not attached. I didn't look into details, but there used to be a technical problem in R C API where you could not pass the right environments to make that work (that bit me when I tried to use S4 a while ago), but I think that has been solved, so conceptually I think this is a bug that could be fixed. This sounds like something that should be possible to fix - even if it means fixing something in R to make it happen. Working around it in hacky ways mentioned here doesn't solve the underlying problem. Cheers, Simon > but this leads to either > > * checking dependencies in R code ... WARNING > 'library' or 'require' call not declared from: ‘methods’ > See the information on DESCRIPTION files in the chapter 'Creating R > packages' of the 'Writing R Extensions' manual. > ... > * checking R code for possible problems ... NOTE > File ‘PkgA/R/binding.R’: > .onLoad calls: > require(methods) > > Package startup functions should not change the search path. > See section ‘Good practice’ in '?.onAttach'. > > with Imports: methods, or > > * checking dependencies in R code ... NOTE > 'library' or 'require' call to ‘methods’ which was already attached by > Depends. > Please remove these calls from your code. > See the information on DESCRIPTION files in the chapter 'Creating R > packages' of the 'Writing R Extensions' manual. > ... > * checking R code for possible problems ... NOTE > File ‘PkgA/R/binding.R’: > .onLoad calls: > require(methods) > > Package startup functions should not change the search path. > See section ‘Good practice’ in '?.onAttach'. > > with Depends: methods > > So is there really any WARNING / NOTE-free way of using the methods package? > > Martin > >> >> -Winston >> >> >> On Mon, Feb 10, 2014 at 8:31 PM, Dirk Eddelbuettel <e...@debian.org> wrote: >>> >>> On 11 February 2014 at 02:53, Kirill Müller wrote: >>> | Why does it seem to be necessary to load the methods package here? >>> >>> "Just use littler (TM pending)". >>> >>> It (auto-)load methods automagically, thanks to Jeff Horner. See below. >>> >>> edd@max:~$ chmod 0755 /tmp/kirill.r >>> edd@max:~$ /tmp/kirill.r >>> [1] "refObjectGenerator" >>> attr(,"package") >>> [1] "methods" >>> edd@max:~$ cat /tmp/kirill.r >>> #!/usr/bin/r >>> >>> newTest <- function() { >>> cl <- get("someClass") >>> cl$new >>> } >>> >>> someClass <- setRefClass("someClass") >>> print(class(someClass)) >>> edd@max:~$ >>> >>> For Rscript, you still need to load it explicitly like any other packages >>> you >>> want to use. >>> >>> Dirk >>> >>> PS New littler release pending in a few days or weeks. The Github repo is >>> current and working. >>> >>> -- >>> Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com >>> >>> ______________________________________________ >>> 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 >> > > > -- > Computational Biology / Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N. > PO Box 19024 Seattle, WA 98109 > > Location: Arnold Building M1 B861 > Phone: (206) 667-2793 > > ______________________________________________ > 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
