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. ______________________________________________ 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.
