[Rd] Darwinian software development and the library function

[Henrik Bengtsson]

Hi.

Here are some guidelines that I find useful:

- Avoid changing the arguments of generic functions provided by the
default R packages, especially the ones in base.  Just, accept those
arguments.  If there are extra arguments you don't like, you can
always add '...' to your method and they will be accepted/pass the R
CMD check.

- Using an S3 generic function that only has '...' arguments seems to
work well and makes all methods for it pass R CMD check, regardless of
what arguments you use in your methods.

- Use R.methodS3 to define your methods, i.e. use setMethodS3("print",
"foo", function(x, ...) { ... }).  This will check if there is a
generic function or not, and if missing, it will be created.
R.methodsS3 was created to make your S3 life easier.

My $.02

Henrik

On Sat, Feb 13, 2010 at 7:40 AM, Charlotte Maia <maiagx at gmail.com> wrote:
> Hi Spencer,
>
> Sorry, I wasn't very clear in my initial post.
> The function print.foo (myfoo, ...) won't pass R check (unless one
> overwrites print first).
> One has to write print.foo (x, ...), which in my personal opinion, can
> be problematic.
>
> In my oosp package, I have overwritten print (along with a few others).
> Initially, I overwrote both print and print.default.
> However now, I merely use print = function (...) base::print (...).
>
> Not really a generic, however it acts exactly the same (I think...).
> Plus Rd documentation still documents print.mymethod in the usual way.
>
>
> kind regards
> Charlotte
>
>
> On Sat, Feb 13, 2010 at 4:41 AM, spencerg <spencer.graves at prodsyse.com> wrote:
>> Hi, Charlotte:
>>
>>     I'm not sure what you mean.  If you mean writing something like
>> "print.foo (myfoo, ...)", this is relatively benign I suppose, but I avoid
>> it where feasible.  On multiple occasions, I've pushed collaborators and
>> even maintainers of other packages to change this or allow me to change it
>> to conform to the standard;  if my memory is correct, there have been
>> several violations of this standard in the "fda" package, which are no
>> longer there because I changed them.  If a user with an object "x" of class
>> "foo" writes print(x=x) or print(foo=x), I'm not sure what it would do, but
>> it might not be what you want.
>>
>>     My "sos" package masks "?".  However, I don't like it.  I generally
>> consider such to be potentially user hostile, and whenever feasible, I
>> prefer to avoid such code.  I did it in this case for a couple of reasons.
>>  First, using "?" (actually "???") seems so much easier to remember than
>> "findFn" that it justifies this transgression of standard protocol.  Second,
>> one of the leading figures in the R community (Duncan Murdoch) contributed
>> suggested we do this and contributed the code.
>>
>>     If you change the definition of "print" itself, that seems to me to be a
>> much bigger issue, with consequences much more difficult to predict.  If
>> someone else also overwrites "print" making it different and incompatible
>> with yours, then your code may not work or theirs may not, depending on
>> which gets loaded first in the search path.  Worse, your code cannot
>> possibly have been tested as thoroughly as the standard code.  If your code
>> includes a subtle bug that only occurs under special circumstances, it may
>> be hard for the person experiencing the problem to find, because they don't
>> expect it.
>>
>>     Hope this helps.
>>     Spencer
>>
>>
>> Charlotte Maia wrote:
>>>
>>> Hi all,
>>>
>>> Legend has it, that polite R programmers don't overwrite, say, the
>>> print function.
>>> However, this seems quite un-Darwinian to me (especially given that I
>>> don't want to call all my arguments x and y).
>>> I might want a function print.foo (myfoo, ...).
>>>
>>> So I decided to be very impolite (in one of my packages) and overwrite
>>> a few standard generics.
>>> Plus, to the best of my knowledge it doesn't interfere with normal use
>>> (yay...).
>>>
>>> This brings us to the library function.
>>> Which by default gives a whole lot of warnings loading my package (and
>>> any other package that does something similar), scaring off polite R
>>> programmers and perhaps some mainstream R users.
>>>
>>> I'm starting to think that the default for library, should be
>>> warn.conflicts=FALSE.
>>> However, just reading the documentation, I noticed a reference to
>>> something called .conflicts.OK.
>>> Not sure what that does, however if it does what it sounds like, then
>>> it largely fixes the problem.
>>>
>>> The biggest issue though, is whether or not one should be impolite
>>> (i.e. Darwinian) and overwrite print etc in the first place...?
>>>
>>> I'm inclined to go in favour of overwriting the functions.
>>> However, it has the potential to introduce some technical problems.
>>>
>>> Other's opinions appreciated.
>>>
>>>
>>> kind regards
>>>
>>
>>
>> --
>> Spencer Graves, PE, PhD
>> President and Chief Operating Officer
>> Structure Inspection and Monitoring, Inc.
>> 751 Emerson Ct.
>> San José, CA 95126
>> ph:  408-655-4567
>>
>>
>
>
> --
> Charlotte Maia
> http://sites.google.com/site/maiagx
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>