[Rd] Proposal: 'global' package refactoring
p.murrell at auckland.ac.nz
Tue Nov 25 00:12:39 MET 2003
I have wanted to figure out a way to do something along these lines for
the many, widely-scattered plotting functions. Something that would be
less invasive (and less useful, but a valid step in the right
direction), is simply a "directory" for different functional groups. A
list of function names, plus descriptions of what they do, plus a
pointer to the package they are in would I think be really useful. A
lot of work to create and maintain, but really useful. For example, the
web pages focused on "spatial projects"
(http://sal.agecon.uiuc.edu/csiss/Rgeo/index.html) has summaries of all
spatially related packages.
The coordination of the DBMS stuff
(http://developer.r-project.org/db/index.html) is another example of
Then of course there is the R GUIs pages (http://www.sciviews.org/_rgui/)
Jan de Leeuw wrote:
> This is a good idea, and it would be great to have these
> refactored meta packages. But it actually implies having
> a group similar to R core that does code review of
> existing packages. For example, what happens if
> a function seems to work but is programmed horribly
> inefficiently ? What happens if something exists on both
> the R and C levels ? What happens with packages that
> rely on private versions of BLAS ? Suppose two packages
> provide the same functionality, how does one choose ?
> And can this be done without coding conventions ? Who is
> in charge ?
> On Nov 24, 2003, at 14:12, Warnes, Gregory R wrote:
>> Looking over the contents of various packages, including my own, it
>> is clear
>> that lots of things end up 'hidden away' in packages where they don't
>> belong. My gregmisc package is a particularly egregious example,
>> something from almost every functional category.
>> I propose that from time to time the R community go through the
>> complete set
>> of packages and 'refactor' the functions and data sets into packages
>> have clearly defined goals. This should make it easier to ensure
>> that new
>> functions get placed into a location where users can easily find them,
>> reduce the amount of re-implementation/duplication existing
>> and assist in ensuring interoperability.
>> It would be worthwhile, for instance, to pull all of the functions
>> to contrasts for generalized linear models into a common location,
>> of having them spread between base, Hmisc, MASS, gregmisc, etc.
>> it would be helpful to pull together all of the genetics-computations
>> into a
>> single location.
>> I recognize that not all package maintainers would be willing to
>> and that not all functions could be easily categorized, but I believe
>> this effort would yield significant benefit and is compatible with
>> the goal
>> of R-core to streamline the base packages.
>> To put my money where my mouth is, I'll volunteer to organize a group
>> to do such a refactoring in conjunction with the userR! 2004 or the next
>> DSC, whichever folks agree is better for this purpose.
>> Gregory R. Warnes, Ph.D.
>> Senior Coordinator
>> Groton Non-Clinical Statistics
>> Pfizer Global Research and Development
>> <<Warnes, Gregory R.vcf>>
>> LEGAL NOTICE\ Unless expressly stated otherwise, this
>> R-devel at stat.math.ethz.ch mailing list
> Jan de Leeuw; Professor and Chair, UCLA Department of Statistics;
> Editor: Journal of Multivariate Analysis, Journal of Statistical Software
> US mail: 8130 Math Sciences Bldg, Box 951554, Los Angeles, CA 90095-1554
> phone (310)-825-9550; fax (310)-206-5658; email: deleeuw at stat.ucla.edu
> homepage: http://gifi.stat.ucla.edu
> No matter where you go, there you are. --- Buckaroo Banzai
> R-devel at stat.math.ethz.ch mailing list
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
64 9 3737599 x85392
paul at stat.auckland.ac.nz
More information about the R-devel