On 6/5/2009 9:41 AM, spencerg wrote:
Liaw, Andy wrote:
From: spencerg
Thank you all for your suggestions. My goal with this
is to make
it as easy as possible for R users to find what they want in
contributed
packages. A referee for our "R Journal" manuscript complained that
"RSiteSearch.function" was too much to type, suggesting we consider
masking "RSiteSearch". From the discussion, I do not see a strong
consensus for doing that. I like Romain's suggestion to shorten the
name further to, e.g., "web.search" or "doc.search". Another
colleague
suggested "RSearch".
What do you think about renaming the current
"RSiteSearch.function{RSiteSearch}" to "RSearch{RSearch}"?
I'm happy to support the consensus of this group on a name (and
even enhancements) that seems likely to maximize its utility to R
users. I ask, because a rose by any other name would smell as sweet,
but one named "prettysweetsmellingthingamabob" might not sell
as well.
Thanks,
Spencer
[I've removed those on cc since I believe everyone will get this through
R-devel anyway...]
I'd suggest something like findFunction() or some such, if the main goal
is to look for functions (not manuals, vignettes, mailing lists, etc.).
"findFunction" sounds to me like the best name I've heard so far.
But it isn't looking for functions, it's looking for help pages about
functions. Another possibility is ???, e.g.
???topic
This is done by masking the utils function `?`, and you'd have to be
careful to pass along requests with one or two (or more than three?)
question marks to the original; it also feels a bit strange to type
hits <- ???topic
though I think it's syntactic and well-defined. I'm not sure how you'd
include your optional arguments, it would be really weird (but again
well defined) to say
z <- ???spline(maxPages = 2)
(Your first example in ?RSiteSearch.function, translated).
Duncan Murdoch
RSiteSearch() was named what it was because it was meant as an interface
to Jon's search site that has lots of things related to R.
It seems to me that the recent discussion has been about including other
alternative search engines, etc. Recall that when we were discussing
including RSiteSearch() into base R, Jon basically had to commit to
maintaining the site, as well as documenting how to replicate the site
if and when he could no longer maintain it, before R Core accepted the
function. I think it would be wonderful to have a search facility
that's all encompassing ("Roogle"?), but for inclusion into base R we
really need to have the sites being searched being basically permenant.
Perhaps a bit OT, but what would really be nice is if a search facility
can not only find functions that's related to some search phrase, but
also indicate whether the packages the functions belong to have already
been installed on the user's system. Sort of like "yum info" or "yum
search" for those on RedHat-based Linux...
The current RSiteSeach package includes that adds other
information from packageDescription to the package summary, adding
(current default) "Title", "Version", "Author", "Maintainer", and (date)
"Packaged". If the package is not installed, these fields are left
blank. I've used this to prioritize which packages (and then which
functions) I should consider first.
Best Wishes,
Spencer
Best,
Andy
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 12:13 PM, Duncan Murdoch
<murd...@stats.uwo.ca> wrote:
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 1:58 AM, Duncan Murdoch
<murd...@stats.uwo.ca>
wrote:
spencerg wrote:
Hello All:
What do you think of adding a function "RSiteSeach"
to the package
of
that name, masking the "RSiteSearch" function in
"utils", trapping any
call
RSiteSearch('searchstring', 'function') to the current
RSiteSearch.function
and passing all others to "utils:::RSiteSearch"? This
was suggested by
a
referee to a manuscript on this new capability
submitted to "R Journal".
The current version of this manuscript is available via
"system.file('doc',
'RSiteSearch.pdf', package='RSiteSearch')" if you have
the "RSiteSearch"
package installed.
I suppose this depends on your long term plans for the
function and
package.
If you think it should eventually replace the utils
function, then it
makes
sense to use the same name: users won't get used to a
new name in the
meantime. But if you think it will diverge from that
function, then you
might as well pick a separate name now.
I disagree with Gabor about this being heavy handed, at
least while it is
the only significant export in the package. If people
don't want it,
don't
attach the package.
The last sentence only gives you a choice of clobbering
the existing
function or not using it and that is not very nice.
What is wanted is
both to be able to use it and allow it to coexist in a nice way.
It is essentially a rename of the existing one to
utils::RSiteSearch. I
would only suggest this if RSiteSearch::RSiteSearch expanded on its
capabilities (which I think was Spencer's proposal),
rather than replacing
them with something different.
How about R changing its RSiteSearch to be an S3 generic with the
main functionality being placed into RSiteSearch.default? Then
RSiteSearch.function can become RsiteSearch.character and
- RSiteSearch will give the new functionality when the package is
loaded and the old functionality if not.
- RSiteSearch.character can be used in place of
RSiteSearch.function
to force only the new functionality (or an error if not present)
- RSiteSearch.default will give the old functionality
whether or not the
package is loaded
(If there is a NAMESPACE then Its assumed here that both
methods are
exported.)
How is that an improvement? Just replace your (RSiteSearch,
RSiteSearch.character, RSiteSearch.default) with (RSiteSearch,
RSiteSearch::RSiteSearch, utils::RSiteSearch) in my
proposal and you get the
same behaviour. The point isn't that Spencer has invented
a way for
RSiteSearch to handle character vectors, it already knows
that. The point
is that he has enhanced it. Or maybe he has written
something similar but
different, in which case he should pick a new name.
Duncan Murdoch
He simply renames it RSiteSearch.character (and possibly some other
changes depending on arguments). Then if the core cooperates
by making RSiteSearch a generic with a default method then
everything
works as one would expect based on an understanding of S3.
No conflicts in names are involved.
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Notice: This e-mail message, together with any attach...{{dropped:15}}
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
