[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