similar to: Comments on R_exts section 1.6.6, Namespaces with S4 classes and methods

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

I fully agree, Michael, that this would be a great thing to have! I have often wondered why R and the standard packages are still sticking so much to the old-style S3 flavor though S4 is part of standard R. I acknowledge that backward compatibility is important, but, as far as I got it, redefining a function or S3 generic as an S4 generic should not harm existing functionality (if done

On 03/27/2014 02:13 AM, Ulrich Bodenhofer wrote: > I fully agree, Michael, that this would be a great thing to have! I have > often wondered why R and the standard packages are still sticking so > much to the old-style S3 flavor though S4 is part of standard R. I > acknowledge that backward compatibility is important, but, as far as I > got it, redefining a function or S3 generic as

Dear developers, the implementation of S4 generics for existing S3 ones in the base package is concerned to be a threat to quick startup times [1]. But since S4 is promoted, and S3/S4 interoperability a pain when package developing [2], are there efforts to improve the situation? E.g. an S3 free system, etc. A good thing [2] is the package 'stats4', including some setGeneric calls (e.g.

The problem is not specific to redefining the q function, but to the interaction of assignInNamespace and setGeneric. The latter requires, roughtly, that the environment of the function being replaced by an S4 generic is (or is the descendent of) the environment in which it lives. E.g., the following demonstrates the problem % R --quiet --vanilla > assignInNamespace("plot",

In pvec(list(1, 2), FUN, mc.cores=2) FUN sees integer() arguments whereas pvec(list(1, 2, 3), FUN, mc.cores=2) FUN sees list() arguments; the latter seems consistent with pvec's description. This came up in a complicated Bioconductor thread about generics and parallel evaluation https://stat.ethz.ch/pipermail/bioc-devel/2012-October/003745.html One relevant point is that a

In > R.version.string [1] "R Under development (unstable) (2011-12-15 r57901)" section 1.6.6 of 'Writing R Extensions' says Note that exporting methods on a generic in the namespace will also export the generic, and exporting a generic in the namespace will also export its methods. and Note that importMethodsFrom will also import any generics defined in

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,

That might be worth thinking about generally, but it would still be nice to have the base generics pre-defined, so that people are not copy and pasting the definitions everywhere, hoping that they stay consistent. On Wed, Mar 26, 2014 at 6:13 AM, Gabriel Becker <gmbecker@ucdavis.edu>wrote: > Perhaps a patch to R such that generics don't clobber each-other's method > tables

The current version of the methods package now has a namespace. Packages using S4 methods and classes can have NAMESPACE files. New directives can be included in NAMESPACE files to import and export classes and methods. Namespaces allow cleaner definition of the API for packages, and are needed for future improvements to R. NOTE: This is a major revision. In principle, it should be back

[cross-posted to R-devel and bioc-devel] Hi, I am trying to implement a 'sort' method in one of the CRAN packages I am maintaining ('apcluster'). I started with using setMethod("sort", ...) in my package, which worked fine. Since many users of my package are from the bioinformatics field, I want to ensure that my package works smoothly with Bioconductor. The problem

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

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

Late to the show on this release, unfortunately. One of our production packages no longer builds under R-2.15.0 with the following message. ** testing if installed package can be loaded Error: Function found when exporting methods from the namespace 'SuperCurve' which is not S4 generic: 'image' Possibly relevant clues follow: ## From R/AllGenerics.R if

On 03/27/2014 06:31 PM, Herv? Pag?s wrote: > On 03/27/2014 02:13 AM, Ulrich Bodenhofer wrote: >> [...] >> >> For the time being, it seems I have three options: >> >> 1) not supplying the sort() function yet (it is not yet in the release, >> but only in my internal devel version) >> 2) including a dependency to BiocGenerics >> 3) leaving the

Ah yes. There they are right on page 4 of "Writing R Extensions". The "LazyLoad: yes" was sufficient to avoid the check errors, but I'll add the "Depends: methods" as well. For the manual-impaired like me, it _may_ be worth reiterating these two requirements in section 1.6.6 "Name spaces with formal classes and methods" - right where the .onLoad

I've installed R-devel R Under development (unstable) (2014-07-09 r66111) Platform: x86_64-apple-darwin13.1.0 (64-bit) and am trying to resolve some problems that I am seeing with my SparseM package. In prior versions I explicitly had: setGeneric("image", function(x, ...) standardGeneric("image")) and then used setMethod to define a method for the class matrix.csr but

Hello R-devel community, I posted a new R 4.0.1 behaviour to stack overflow (https://stackoverflow.com/questions/62327810/inconsistent-error-handling-of-function-and-s4-generics-on-r-4-0-1), where I think it is an undesired or unexpected change in 4.0.1. Attributes of errors seem to be lost or obscured when encountered in an S4 generic context. An example of this being undesirable comes in shiny

Hi, further down from the problem I asked about yesterday I encounter the following problem (please appologize for the lengthy mail - I have not found a brief example making the issue clear): - using R packages making use of namespaces & - S4 classes when using --with-package-versions in the install call: Pkgs install ok and the first pkg 'base' can be loaded in R

>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>> on Wed, 18 Apr 2018 14:16:37 -0700 writes: > Hi Bill, > Ideally, your coworker would just make an alias (or shortcut or > whatever) for R that passed --no-save to R. I'll try to look into this > though. > Michael Yes, indeed! As some of you know, I've