From hb at stat.berkeley.edu  Sat Feb 13 16:10:30 2010
From: hb at stat.berkeley.edu (Henrik Bengtsson)
Date: Sat, 13 Feb 2010 16:10:30 +0100
Subject: [Rd] Darwinian software development and the library function
In-Reply-To: <b7bfe54e1002122240m4e633e03m3f3089096ef70d54@mail.gmail.com>
References: <b7bfe54e1002111959l710b621fmc3b2a90d77a3771a@mail.gmail.com>
	<4B75768F.8020904@prodsyse.com>
	<b7bfe54e1002122240m4e633e03m3f3089096ef70d54@mail.gmail.com>
Message-ID: <59d7961d1002130710t6c2507a5i177c26d173d94c97@mail.gmail.com>

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
>



[Rd] Darwinian software development and the library function
Henrik Bengtsson