[Rd] proposed changes to RSiteSearch

spencerg spencer.graves at prodsyse.com
Thu Jun 4 19:38:37 CEST 2009


Gabor Grothendieck wrote:
> On Thu, Jun 4, 2009 at 12:13 PM, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
>   
>> Gabor Grothendieck wrote:
>>     
>>> On Thu, Jun 4, 2009 at 1:58 AM, Duncan Murdoch <murdoch at 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.
>
>   
To clarify:  RSiteSearch.function{RSiteSearch} accesses Johathan Baron's 
RSiteSearch data base for functions only, returning the result as a 
data.frame, sorts it to put the most frequently cited package first and 
then help page within package. 

      Spencer
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>



More information about the R-devel mailing list