Re: [Rd] Depot for S3 to S4 generics (as in stats4)?
On 06/07/2014, 6:23 AM, Sven E. Templer wrote: > 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. for summary, plot, ...) which I can 'importFrom' to a > NAMESPACE. Nevertheless, functions as as.matrix, as. dist, merge, > duplicated, and for sure some others, are not available as S4 > generics. > So my question is: will the base/graphics/... S3 generic definitions > for S4 methods be completely implemented in a future R release? > (E.g. in base4/stats4,/graphics4/... (by heritage [3]) or combined by > a single package such as genericS4) I would not do that, and I haven't seen anyone else announcing plans to do it, but the question is pretty open ended. I'm reluctant to make predictions about what R will look like in the indefinite future. I would be confident in guessing that R 3.2.x won't include it (but I could be wrong, if someone takes it on). If you want to make it happen sooner, you need to find an R Core member to work with. Presumably the responses to your posting will indicate the level of interest in working on this. Duncan Murdoch > Sorry I couldn't get more information from the devel archive (or find > a solution/answer) since the same idea already has been mentioned in > 2007 [4]. Thank you for clarifying in advance. > > Sincerely, > Sven > > [1] > http://r.789695.n4.nabble.com/An-update-method-for-lists-td912749.html#a912756 > [2] my opinion > [3] > http://r.789695.n4.nabble.com/improved-error-message-when-existing-implicit-S4-generic-is-not-imported-td4421688.html#a4436278 > [4] http://developer.r-project.org/BDR_S4issues.txt > > __ > 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
[Rd] Depot for S3 to S4 generics (as in stats4)?
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. for summary, plot, ...) which I can 'importFrom' to a NAMESPACE. Nevertheless, functions as as.matrix, as. dist, merge, duplicated, and for sure some others, are not available as S4 generics. So my question is: will the base/graphics/... S3 generic definitions for S4 methods be completely implemented in a future R release? (E.g. in base4/stats4,/graphics4/... (by heritage [3]) or combined by a single package such as genericS4) Sorry I couldn't get more information from the devel archive (or find a solution/answer) since the same idea already has been mentioned in 2007 [4]. Thank you for clarifying in advance. Sincerely, Sven [1] http://r.789695.n4.nabble.com/An-update-method-for-lists-td912749.html#a912756 [2] my opinion [3] http://r.789695.n4.nabble.com/improved-error-message-when-existing-implicit-S4-generic-is-not-imported-td4421688.html#a4436278 [4] http://developer.r-project.org/BDR_S4issues.txt __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] useDynLib
I would like to be able to load two versions of a package at once and to do that was thinking of giving each version a different package name in the DESCRIPTION file and the building and installing each such version separately. library(myPkg1) library(myPkg2) and then use myPkg1::myFun() and myPkg2::myFun(). To do that easily it would be convenient if one could change the package name in only one place (the DESCRIPTION file) and have that propagate to all other uses of the package name in the package. Suppose the package were named "myPkg". Then the problem areas are: 1. The NAMESPACE file has myPkg hard-coded like this: useDynLib(myPkg, .registration=TRUE) 2. The configure.ac file has myPkg hard-coded like this: AC_INIT([myPkg], 1.0.0) 3. There are various references to myPkg hard-code throughout the R code, e.g. myPkg::myFun, but I am ok here as I assume this would work where an .onLoad would be used to grab the package name from the .onLoad's pkgname argument: `::`(pkgname, MyFun) (Also some or all of these may not be needed in the first place.) 1. Is there some way to cause these instances to change when the package name in the DESCRIPTION file changes or is there some other approach that would make it easy to change the package name in just one spot or some other way to load two packages that are versions of each other at one time. (The fact that the package has C++ code seems to be the complicating factor.) 2. Are there any examples of CRAN packages that have been set up to make this easy to do? Thanks. -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] request for "minor" fix to src/library/tools/QC.r
hi. i was hoping to automatically set the Version: number in my package
description file (image2k-package.Rd) in the man directory by using a
.in file in the same directory. "R CMD build" excludes the .in file
because the routine .check_package_subdirs() in QC.R (which build calls)
doesn't like that file.
.check_package_subdirs() also checks files in R/, and at *that* point in
the code says "now configure might generate files in this directory" and
explicitly allows any files that end in .in. i wonder if that code
could be duplicated for the case of files in man/? a diff to that
effect (just copying three lines from the immediately prior case for R/)
is provided below.
(as a check as to the viability of this, i manually added my
man/image2k-package.in file to the tarball built by build, and both
check and install seemed to survive without any problems. a sample size
of 1 is *always* my favorite. :)
cheers, Greg Minshall
--- src/library/tools/R/QC.r2014-03-25 01:15:06.0 +0200
+++ src/library/tools/R/mod-QC.r2014-07-06 14:05:46.0 +0300
@@ -4372,6 +4372,9 @@
full.names = FALSE,
OS_subdirs = OS_subdirs)
wrong <- setdiff(all_files, man_files)
+## now configure might generate files in this directory
+generated <- grep("\\.in$", wrong)
+if(length(generated)) wrong <- wrong[-generated]
if(length(wrong)) {
wrong_things$man <- wrong
if(doDelete) unlink(file.path(dir, "man", wrong))
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
