On Dec 11, 2009, at 4:56 PM, Peng Yu wrote:
On Fri, Dec 11, 2009 at 3:49 PM, Steve Lianoglou
<mailinglist.honey...@gmail.com> wrote:
On Dec 11, 2009, at 4:45 PM, Peng Yu wrote:
On Fri, Dec 11, 2009 at 2:37 PM, Charlie Sharpsteen
<ch...@sharpsteen.net> wrote:
On Fri, Dec 11, 2009 at 10:24 AM, Peng Yu <pengyu...@gmail.com>
wrote:
How do you figure out all the possibilities?
Well, the "Value" section of the third party function's help page
should
outline the return types it produces. If it doesn't cover all
cases, write
a letter to the package maintainer. If you are using third party
functions
that are not packaged with help pages, then this sort of
uncertainty is part
of using unpublished code.
A document may not document all the corner cases. Even if it is so,
you can never be sure unless all the possibilities are examined .
No, you can be sure. Just look at the code of the function that is
ill behaved.
One purpose of packaging code is to shield the user from necessarily
knowing the details. This practice clear break this purpose. I'm not
saying that I can not read the source code if it is really needed. But
relying on users to read the code in order to use the package is not a
good software engineering practice.
As Don asked: are you actually experiencing this problem with a
library on CRAN?
Not the particular the 'NULL' problem. But the different return types
of many functions have already caused a lot of headache to me.
I think you lost a lot of sympathy within this audience when you not
only admitted that you did not read the help pages, but insisted that
your failure to do so was somehow the responsibility of the authors
for not have written it in exactly the format you preferred.
--
David Winsemius, MD
Heritage Laboratories
West Hartford, CT
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
