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 <mai...@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.gra...@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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel