[Rd] Proposal: 'global' package refactoring
John Fox
jfox at mcmaster.ca
Tue Nov 25 14:33:45 MET 2003
Dear Gregory, Paul, and Jan,
I recall proposing something like this (that is, a classification of
available functions) some time ago, but it never got off the ground. The
advantage of using keywords is that package authors would classify their
own functions, but I don't think that the current set of keywords is
adequate. It would be particularly useful to work out a hierarchical or
perhaps hyper-linked classification (without restricting particular
functions to just one terminal node).
Regards,
John
At 09:29 PM 11/24/2003 -0500, Warnes, Gregory R wrote:
>How about we use the information already stored in \keyword{}?
>
>It should be straighforward to allow navigating among the \keyword
>hirearchy.
>
>-G
>
>-----Original Message-----
>From: Paul Murrell
>To: Jan de Leeuw
>Cc: Warnes, Gregory R; 'R-devel at stat.math.ethz.ch'
>Sent: 11/24/03 6:12 PM
>Subject: Re: [Rd] Proposal: 'global' package refactoring
>
>Hi
>
>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
>something similar.
>Then of course there is the R GUIs pages
>(http://www.sciviews.org/_rgui/)
>
>Paul
>
>
>
>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,
> >> 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
> >
> > ______________________________________________
> > R-devel at stat.math.ethz.ch mailing list
> > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
>
>
>--
>Dr Paul Murrell
>Department of Statistics
>The University of Auckland
>Private Bag 92019
>Auckland
>New Zealand
>64 9 3737599 x85392
>paul at stat.auckland.ac.nz
>http://www.stat.auckland.ac.nz/~paul/
>
>
>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
-----------------------------------------------------
John Fox
Department of Sociology
McMaster University
Hamilton, Ontario, Canada L8S 4M4
email: jfox at mcmaster.ca
phone: 905-525-9140x23604
web: www.socsci.mcmaster.ca/jfox
More information about the R-devel
mailing list