search for: exportmethod

Hi, I'm hoping to get some clarification of the intent of some of directives used in NAMESPACE files. 1. Is import(somePkg) also intended to import all classes and methods that are exported via exportClasses and exportMethods in somePkg? I think import pulls in classes and methods, but it isn't clear from the docs whether this is as intended. 2. What is exportMethods intended to do? I'm confused about when/if exportMethods deals with a generic function vs method(s) for a generic function. a) I...

We are building a package, and want to create S4 methods for both head and mean for our own BigMatrix class. Following the recommendation in "Writing R Extensions" we use exportMethods instead of export in NAMESPACE (this is described as being "clearer"). This works for head, but not for mean. Obviously we importFrom(utils, head), but don't need to do this for mean, which is imported automatically from base. If we export(mean) rather than exportMethods(mean), it...

...ious other R files... setMethod("image", signature(x="RPPA"), ... setMethod("image", signature(x="RPPADesign"), ... And then exported them for use outside the package. ## NAMESPACE import(methods) importFrom("graphics", image) exportClasses(....) exportMethods(image) If the problem is because of the exportMethods(), I'm left stumped as to how to work around this. Making our S4 objects useable externally was kind of the point. Source package available, if needed. oompa <- "http://bioinformatics.mdanderson.org/OOMPA/2.14" download.pa...

I have a question about what to do in the following situation (please bear with the setup): Package A defines an S4 generic 'foo' and as well as S4 methods for 'foo' and has exportMethods("foo") in its NAMESPACE file. Package B defines another method for 'foo' for class "bar" and has importFrom(A, "foo") exportMethods("foo") exportClasses("bar") in its NAMESPACE file. Should Package B also have Package A in the 'Dep...

...dicates that one should setGeneric("unique") setClass("A") unique.A <- function(x, incomparables=FALSE, ...) {} setMethod(unique, "A", unique.A) Both S3 and S4 methods need to be exported in the NAMESPACE import(methods) S3method(unique, A) exportMethods(unique) PkgB introduces a new class and method setClass("B") unique.B <- function(x, incomparables=FALSE, ...) {} setMethod(unique, "B", unique.B) and in the NAMESPACE has import(methods) importFrom(PkgA, unique) S3method(unique, B) exportMethods(uni...

...compatible, and it passes 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. Similar...

pkgA's NAMESPACE has importFrom(graphics, plot) exportClasses("A") exportMethods("plot") R/foo.R has setClass("A") setMethod("plot", "A", function(x, y, ...) {}) During R CMD INSTALL pkgA_1.0.tar.gz we are told ** preparing package for lazy loading Creating a generic function for 'plot' from package 'graphics' i...

...oduced by package.skeleton More generally one should of course think about any number of arguments e.g. gf(x,y) with y of any of the classes A B or C and methods: gf#A#A gf#A#B gf#A#C gf#B#A ... and so on I would then like to 1.) export methods only for a list of signatures with an extended exportMethod statement in the the NAMESPACE file . whose syntax could look like: exportMethod( gf,signatures=list(c(A,B),c(A,C))) where the omitted signatures argument defaults to the behavior already implemented by exportMethods. 2.) hide any method with a signature >>containing<< a...

...ds on creates a generic, use that generic instead of creating your own'. The former introduces artificial dependencies on stats4, the latter allows for several independently defined S4 generics on plot. Neither is satisfactory. Dozens of Bioconductor packages importFrom(graphics, plot) and exportMethods(plot), in addition to other common functions. Our solution has been to create a package BiocGenerics whose purpose is to create and document otherwise implicit generics of base packages (see ?BiocGenerics for a list of generics). Packages then Import: BiocGenerics and importFrom(BiocGenerics,...

...a package author reports that S4 dispatch fails. I can reproduce this with a PkgA (attached; 'intervals' is a relatively light-weight CRAN package) that has DESCRIPTION with Depends: intervals Imports: graphics NAMESPACE: importFrom(graphics, "plot") export("plot") exportMethods("plot") R/tmp.R setClass("A") setMethod("plot", "A", function(x, y, ...) {}) and then > library(PkgA) Loading required package: intervals > plot function (x, y, ...) UseMethod("plot") <environment: namespace:graphics> notice tha...

Dear all, I am experiencing some problems with S4 method overloading. I have defined a generic for graphics:plot, using setGeneric("plot", useAsDefault = plot) and with importFrom('graphics', 'plot') and exportMethods('plot') in the NAMESPACE file of pkg A. I then proceed to define a method for signature c('myS4class', 'missing'). This works as expected: selectMethod('plot', c('myS4class', 'missing')) returns the newly defined method, and the method gets called w...

..."numeric"), contains = "track") setMethod( ".DollarNames", signature( x = "track", pattern = "character" ), function(x, pattern){ grep( pattern, c("foo", "bar"), value = TRUE ) } ) and the NAMESPACE : import( utils ) exportMethods( .DollarNames ) exportClasses( track, trackCurve ) When I load the package, I can call .DollarNames explicitely : > require( foo ) > x <- new( "trackCurve", x = 1:10, y = 1:10, smooth = 1:10 ) > .DollarNames( x, "f" ) [1] "foo" but completion does n...

...in loadNamespace(package, c(which.lib.loc, lib.loc), keep.source = keep.source) : in 'woof1' classes for export not defined: dog Error: package/namespace load failed for 'woof1' Execution halted Here's the NAMESPACE importFrom(graphics,plot) exportClasses("dog") exportMethods("plot","show") thanks yet again, Sincerely, Erin mailto: hodgess at gator.uhd.edu

...m. It has setClass("A") setClass("B", contains="A") setMethod("show", "A", function(object) cat("A\n")) setMethod("show", "B", function(object) cat("B\n")) with NAMESPACE import(methods) exportClasses(A, B) exportMethods(show) This creates the object and illustrated expected behavior ~/tmp$ R --vanilla --slave -e "library(PkgA); b = new('B'); save(b, file='b.Rda'); b" B Loading PkgA before the object leads to correct dispatch ~/tmp$ R --vanilla --slave -e "library(PkgA)...

...contains="numeric",S3methods=TRUE) [1] "B" > format.B <- function(x, ...) "Don't make it bad" > b<-new("B",1968) > formatMe(b) [1] "Don't make it bad" Could the problem be in Test's NAMESPACE file? There is only one line: exportMethods(formatMe) Here is Test's DESCRIPTION file: Package: Test Type: Package Title: Testing format Version: 1.0 Date: 2010-06-22 Author: Dan Murphy Maintainer: Dan Murphy <snipped> Depends: methods Description: Does format in a package work with S4 format method? License: GPL (>= 2) LazyLo...

...base::q, .GlobalEnv, to be loaded as a namespace, causing the error. Giving his replacement q function the environment getNamespace("base") avoids the problem. I can reproduce the problem by making a package that just calls setGeneric("as.hexmode",...) and a NAMEPACE file with exportMethods("as.hexmode"). If my .Rprofile puts a version of as.hexmode with environment .GlobalEnv into the base namespace, then I get the same error when trying to load the package. I suppose this is mostly a curiosity and unlikely to happen to most people but it did confuse us for a while. Bil...

...list") <- from obj } <environment: namespace:methods> Entries in .MTable should be MethodDefinition objects (or at least that is what is usually there for methods defined via setAs). It happens that if you try to load a package that has a NAMESPACE file with a directive exportMethods(coerce) but no call to setAs then you get an error: library("hello") Error in .mergeMethodsTable(generic, mtable, get(tname, envir = env), : Invalid object in meta table of methods for "coerce", label "list#A", had class "function" So I...

...ure, fdef, where) : in the method signature for function "plot" no definition for class: "validation" ** help *** installing help indices ... Maybe my NAMESPACE file looks wrong. Has anybody an idea how it has to look like to solve this problem? ( I use exportClasses(...), exportMethods(...). ) I have 3 classes: 'prediction', 'validation', 'nvalidation' which have a plot function. There's no warning for class 'nvalidation' but for the other two. Any suggestions? Greetings. Dan

...d on unique DESCRIPTION Imports: methods, PkgA R/f.R: setClass("B", representation(b="numeric")) setMethod(unique, "B", function(x, incomparables=FALSE, ...) unique(x at b)) NAMESPACE: importFrom(PkgA, unique) exportClasses(B) exportMethods(unique) There is a man/ page for each package, but no other documentation. Yet R CMD check PkgA_1.0.tar.gz says * checking for missing documentation entries ... OK * checking for code/documentation mismatches ... OK and for Pkg B we only get * checking for missing documentation entries ....

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(gener...