[Rd] Proposal: 'global' package refactoring

Gregory R. Warnes greg at warnes.net
Tue Nov 25 03:43:59 MET 2003


I have great faith in the R comminity's ability to come to consensus.  
One can (and should) avoid 'troublesom' issues / packages in a first 
pass.  These can come later.  Further, once we get the ball rolling, we 
may be able to convince the community to change from 'I have a neat 
function, lets make a package!' to 'I have a neat function.  It belongs 
in package  XXXXX'.)

I would imagine that the first step of this process would be to draft a 
recommended package structure along with a list of what functions 
belong where.  This would then be submitted *as a proposal* to R-core, 
who would have (of course) the final say on the structure.   A package 
author will continue to be free to package and distribute his own work 
in any way that he wants (consistent with the license of code he's 
borrowed, of course.), although most authors will be pleased that thier 
code has been deemed 'worthy' of admission into the base set.

I further recommend, that JStatSoft be used as a peer-recongnition 
system for functions that get included in the 'standard R extension 
packages' that result.   These will, of course, have been peer 
reviewed! This would meet a two-fold need.  First, it would provide 
peer recognition for code that is not suficciently substantial to merit 
its own packaage, making it easier for new contributors to participate. 
  (Many of the components of gregmissc actually fall into this 
category.)  Second, it will demonstrate the *volume* of contributions 
by individuals by the number of inclusions.  Of course, there would 
need to be a reasonable minimum size/worth requirement to be recognized 
in this fashon.   Smaller contributions will continue to be recognized 
by listing the names of all contributors in a master list.

Further on, it will become possible to de-centralize the management of 
the package system so that certain individuals would take up management 
of specific package areas, (e.g. Paul Murrrel for graphics, etc.)





-----Original Message-----
From: Jan de Leeuw
To: Warnes, Gregory R
Cc: 'R-devel at stat.math.ethz.ch'
Sent: 11/24/03 5:36 PM
Subject: Re: [Rd] Proposal: 'global' package refactoring

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,
 > containing
 > 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
 > that
 > 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
 > functionality,
 > and assist in ensuring interoperability.
 >
 > It would be worthwhile, for instance, to pull all of the functions
 > related
 > to contrasts for generalized linear models into a common location,
 > instead
 > of having them spread between base, Hmisc, MASS, gregmisc, etc.
 > Similarly,
 > 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
 > participate
 > and that not all functions could be easily categorized, but I believe

 > that
 > 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

 > effort
 > 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
 > messag...{{dropped}}
 >
 > ______________________________________________
 > R-devel at stat.math.ethz.ch mailing list
 > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
 >
===
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
                     http://gifi.stat.ucla.edu/sounds/nomatter.au



More information about the R-devel mailing list