Re: [Rd] proposed changes to RSiteSearch

From: spencerg <spencer.graves_at_prodsyse.com>
Date: Fri, 05 Jun 2009 17:32:11 -0700

Dear Andy, Duncan, et al.

      Based on comments from Andy and Duncan, I'd like to revise my proposal as follows:

  1. Rename the current "RSiteSearch.function" to "findFunction" and the package name from "RSiteSearch.function" to "findFunction", with "findFun" being an alias for "findFunction".
  2. Try to write code so '???"differential equation"(999)' works the same as 'RSiteSearch.function("differential equation", 999)' does now.

      What do you think? I've made this as two steps, because I can do "1" myself, but I may need help to develop "2".

      Thanks again for all your suggestions.
      Best Wishes,
      Spencer


Duncan Murdoch wrote:

> 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       

>>>> <murdoch@stats.uwo.ca> wrote:
>>>>
>>>>>        
>>>>>> Gabor Grothendieck wrote:
>>>>>>            
>>>>>>> On Thu, Jun 4, 2009 at 1:58 AM, Duncan Murdoch           

>>>> <murdoch@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_at_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_at_r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________
R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Sat 06 Jun 2009 - 00:36:06 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Sat 06 Jun 2009 - 18:35:16 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive