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
