search for: importclassesfrom

If a package has importClassesFrom(P, C) in its NAMESPACE, then should it _also_ have importClassesFrom(P, <superclasses of C exported from P>) importClassesFrom(Q, <superclasses of C exported from Q>) ## and so on ... ? I think that WRE could be more clear on this point, and in any case I _think_ that...

...on(lib, pkg) require(methods)". Do I also have to import the namespace of "methods" package? 2) If I use import("pkg1") in the namespace of "pkg2", does this also (correctly) import the S4 classes and methods of "pkg1"? Or do I explicitly have to use importClassesFrom resp. importMethodsFrom? 3) If I import the Namespace of "pkg2" in "pkg3", where the namespace of "pkg2" has import("pkg1") (or maybe importClassesFrom, importMethodsFrom) and I also want to use S4 classes and methods of "pkg1" in "pkg3&quo...

...to worry about this? If so, what can I do about it? I suppose I could add an importFrom directive, but it will be a pain unless there is an "allbut(diag)" option I'm not aware of. (I assume that methods and classes can be listed in importFrom, i.e., there are no importMethodsFrom or importClassesFrom functions). 2. If I don't need to worry, is there a way to turn the message off? I as a developer need to see it, but users don't and it may worry them unnecessarily. Updating all 17 of my test/*.Rout.save files is a nuisance as well, but only a nuisance. I'd like to upload this to...

...~ bar ...)) tab <- attr(smry, "AICtab") tab$AIC When I run this code as a regular R script everything works fine, tab$AIC has the desired value. But when I try to run this code from within a package I wrote, tab$AIC is NULL. I've tried adding "import(lme4)", "importClassesFrom(lme4)" and "importMethodsFrom(lme4)" into the NAMESPACE file of my package, but it didn't help, tab$AIC is still NULL. Thanks for any kind of hint! Best Regards, Ben

...tine1) useDynLib(packageName, routine2) in the NAMESPACE file, instead of separate (wrong) useDynLib statements as before. * All namespace import directives now behave in the same way as the export directives, producing multiple single directives instead one multiple directive: `@importClassesFrom pkg a b` now produces `importClassesFrom(pkg, a)` and `importClassesFrom(pkg, b)` * In example files included with `@example` you can now use infix operators (e.g. %*%) or other things with %, because they will be preceded by a backslash in the Rd file. This behaviour was already in place fo...

...tine1) useDynLib(packageName, routine2) in the NAMESPACE file, instead of separate (wrong) useDynLib statements as before. * All namespace import directives now behave in the same way as the export directives, producing multiple single directives instead one multiple directive: `@importClassesFrom pkg a b` now produces `importClassesFrom(pkg, a)` and `importClassesFrom(pkg, b)` * In example files included with `@example` you can now use infix operators (e.g. %*%) or other things with %, because they will be preceded by a backslash in the Rd file. This behaviour was already in place fo...

...asses the checks (on linux). But approach with caution, namespaces do change the language semantics, and we will likely encounter some surprises. The new directives, in addition to those described in Luke Tierney's article in the June, 2003 R News, are: exportClasses(...) exportMethods(...) importClassesFrom(package, ...) importMethodsFrom(package, ...) The `...' arguments are the names of classes or of generic functions as appropriate. The exportClasses and exportMethods directives export the corresponding class definitions and all the methods for the functions. Similarly, the importClassesFrom...

...4-10-06) on windows 2000. I tried to use "setClassUnion" in a package I am currently working on. The situation is similar to the following example: The DESCRIPTION file has entries: Depends: R (>= 2.0.0), methods Imports: methods LazyLoad: yes The NAMESPACE file has entries: importClassesFrom("methods", "NULL", "numeric") exportClass("OptionalNumeric", "class1", "class2") The example R code is: .onLoad <- function(lib, pkg){ require("methods", character = TRUE, quietly = TRUE) } setClassUnion("Optional...

...4-10-06) on windows 2000. I tried to use "setClassUnion" in a package I am currently working on. The situation is similar to the following example: The DESCRIPTION file has entries: Depends: R (>= 2.0.0), methods Imports: methods LazyLoad: yes The NAMESPACE file has entries: importClassesFrom("methods", "NULL", "numeric") exportClass("OptionalNumeric", "class1", "class2") The example R code is: .onLoad <- function(lib, pkg){ require("methods", character = TRUE, quietly = TRUE) } setClassUnion("Optional...

If a package defined an S3 generic and an S4 generic for the same function (so as to add methods for S4 classes to the existing code), how do I set up the namespace to have them exported? With import(stats) exportMethods(bigglm) importClassesFrom(DBI) useDynLib(biglm) export(biglm) export(bigglm) in NAMESPACE, the S3 generic is not exported. > methods("bigglm") [1] bigglm.RODBC* bigglm.data.frame* bigglm.function* Non-visible functions are asterisked Warning messages: 1: In findGeneric(generic.function, parent.frame()...

Hi, I have a S3 package with namespace called "myS3Pkg". Inside my package I would like to create a S4 class which extends (adds 2 slots) another S4 class from some other package. The class should be created in "myPkg" environment (and not global environment). Using: setClass("myS4class", representation("otherS4class", mydata = "numeric"),

...ESCRIPTION file or is it correct to import Package A only? Finally, Package C has a single exported function named 'myfunc' which needs to use the method for 'foo' defined in Package B, so its NAMESPACE file has importFrom(A, "foo") importMethodsFrom(B, "foo") importClassesFrom(B, "bar") export("myfunc") Is this the correct thing to do? The error I get under this setup is that 'myfunc' cannot find the method for 'foo' defined in Package B when 'myfunc' calls 'foo' on an object of class "bar". If you've...

...at gmail.com I can replicate this with a simpler example, where PkgA has setClass("A", representation(x="numeric")) with NAMESPACE import(methods) exportClasses("A") PkgB has setClass("B", contains="A") NAMESPACE import(methods) importClassesFrom("PkgA", "A") exportClasses("B") and then library(PkgA); library(PkgB) setClassUnion("C", c("matrix", "A")) setGeneric("do", function(x) standardGeneric("do")) setMethod("do", "C", functio...

...quot;coeftab",object) coeftab.default <- function(object,...) { print(class(summary(object))) coef(summary(object)) } The NAMESPACE tries to pull in the necessary bits and pieces from lme4 to extract summaries and coefficients: export("coeftab","coeftab.default") importClassesFrom(lme4,"mer","summary.mer") importMethodsFrom(lme4,"coef","summary","show","print") exportMethods("coef","summary","show","print") exportClasses("mer","summary.mer") S3method(coefta...

The package 'graph' defines classes graph and graphNEL (extending graph) and a union,graph,graph-method. These are all exported and fully documented. The package 'GSEABase' Imports: graph and importClassesFrom(graph, graphNEL). GSEABase defines methods on union for its own classes (not graph / graphNEL), and has exportMethods(union). union,graph,graph-method is not used in GSEABase. R version 2.8.0 Under development (unstable) (2008-06-08 r45879) reports from R CMD CHECK GSEABase * checking for missing...

...metadata object in order to make a copy of it (or does it just copy a name which binds to the original metadata object - I'm not clear on that). What is the danger I am being warned about, and what, ideally should I do about it? In practice I know I can make the message go away by using `importClassesFrom(rgeos,SpatialLinesNULL)` in my NAMESPACE file now that Edzer Pebesma has arranged for a version of rgeos which exports SpatialLinesNULL. But why do I need to explicitly import the superclass of the class I am actually using? If I were using a *function* from rgeos, which in turn utilised a s...

...uot;barprint method for bar" [1] 99 Fine. Here is the bit that I have not figured out. ------------- #the .r file for package waz wazbar <- function(x) { barprint(new("bar",x)) } #the NAMESPACE file for package waz import(methods,barpkg) importMethodsFrom(barpkg) importClassesFrom(barpkg) export(wazbar) #then in R > require(wazpkg) Loading required package: wazpkg [1] TRUE > wazbar(99) Error in .setMethodsForDispatch(f, fdef, resetMlist) : Internal error: did not get a valid generic function object for function "print" Error in print("barprin...

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

...copy a name which binds to the original metadata >> object - I'm not clear on that). What is the danger I am being warned >> about, and what, ideally should I do about it? >> >> >> >> In practice I know I can make the message go away by using >> `importClassesFrom(rgeos,SpatialLinesNULL)` in my NAMESPACE file now that >> Edzer Pebesma has arranged for a version of rgeos which exports >> SpatialLinesNULL. >> >> >> >> But why do I need to explicitly import the superclass of the class I am >> actually using? If I...

...copy of it (or does it just copy a name which binds to the original metadata > object - I'm not clear on that). What is the danger I am being warned > about, and what, ideally should I do about it? > > > > In practice I know I can make the message go away by using > `importClassesFrom(rgeos,SpatialLinesNULL)` in my NAMESPACE file now that > Edzer Pebesma has arranged for a version of rgeos which exports > SpatialLinesNULL. > > > > But why do I need to explicitly import the superclass of the class I am > actually using? If I were using a *function* from...