Re: [Rd] Darwinian software development and the library function
Hi, Charlotte:
I'm with Henrik: I don't know the global consequences of print
= function (...) base::print (...), but I wouldn't do it.
Writing print.foo (x, ...) may violate your sense of
aesthetics, but I avoid it. I've done things like that in the past,
then changed them to match the standard. I've also gotten others to
change their code or agree to let me change it to match the standard.
As I previously mentioned, some of the code in my sos package violates
a standard. However, there were more substantive reasons than just
aesthetics.
I hope you'll entertain other analogies: If red lipstick is
required for something I want to support, I'll wear red lipstick, even
if I think blue would go better with my outfit. Shaving is a pain in
the face, and I wore a flaming red beard for a quarter century until it
finally came in white. Then I started shaving to avoid projecting the
image of a broken down old man; people said I looked 25 years younger.
(Younger than what?) You can post a question to r-devel in Urdu or
Farsi, but I doubt of many people will reply.
Hope this helps.
Spencer
On 2/13/2010 7:10 AM, Henrik Bengtsson wrote:
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 Maiamai...@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, spencergspencer.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
Re: [Rd] Darwinian software development and the library function
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
Re: [Rd] Darwinian software development and the library function
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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Darwinian software development and the library function
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
[Rd] Darwinian software development and the library function
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 -- Charlotte Maia http://sites.google.com/site/maiagx __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
