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

===
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@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