From feh3k at spamcop.net  Sat Jan 17 15:33:10 2004
From: feh3k at spamcop.net (Frank E Harrell Jr)
Date: Sat Jan 17 15:31:58 2004
Subject: [Rd] Wish list
Message-ID: <20040117093310.29ee370a.feh3k@spamcop.net>

Kevin,

I was glad to see your list.  Some of the items were reasons for creating
some of the functions in Hmisc.  summarize and mApply in conjunction with
llist handle labeling of output - this is actually quite tricky and the
Hmisc solution isn't perfect.  Dropping unused factor levels by default
(with easy override) is an old battle and I agree with you completely that
for everyday data analysis I almost always want to do this.  But I haven't
been able to convince anyone else about that, despite repeated attempts. 
[.factor in Hmisc drops unused levels by default.  To be honest, the one
place I've gotten into trouble with this default occasionally is in
multiple panels in lattice related to consistent assignment of line styles
and symbols across strata when the "groups" variable has missing cells in
some panels.

I also share your views about namespaces.  These have caused numerous
problems for me.  It would be nice to have more of a mechanism to put
"feelers" out to the R user community when major changes are planned. 
Namespaces seemed to appear on the scene quite quickly.  I do see some
advantages for them though.  By contrast, I have been very relieved that
S4 classes have not posed a problem for my code that relies on "old"
classes (totally unlike my experience with S-Plus) but any time changes
are made that involve some incompatibilies with old code there should be
some pause.

In Hmisc and Design I reference several functions that were not exported
from packages that now use namespaces.  There is an elegant solution with
the package:::function notation, but I have been unable to use this
solution because I use one code base for all versions of R and S-Plus. 
This notation generates syntax errors in all but late versions of R.

Let me add to the wish list the creation of some mechanism to better track
improvements and bug fixes in packages, such as a change log link by each
package's area in CRAN, or easy access to CVS information from there. 
When I report bugs (e.g., in read.xport in foreign [due somewhat to
problems inherent with SAS's format] or ace or avas in acepack) it would
be nice to see some announcement when the bugs are resolved, or to easily
track this.  Even a checkbox that the package maintainer has seen the bug
report even if she/he currently does not have time to work on it would be
very helpful, as would a notation that the bug report was found to be
"buggy".

Frank

---
Frank E Harrell Jr   Professor and Chair           School of Medicine
                     Department of Biostatistics   Vanderbilt University


[Rd] Wish list
Frank E Harrell Jr