[R] Why a list of NULL's are reduced to NULL?

[Steve Lianoglou]

On Dec 11, 2009, at 4:56 PM, Peng Yu wrote:

> On Fri, Dec 11, 2009 at 3:49 PM, Steve Lianoglou
> <mailinglist.honeypot at 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
>>> <chuck at sharpsteen.net> wrote:
>>>> On Fri, Dec 11, 2009 at 10:24 AM, Peng Yu <pengyu.ut at 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.

This is an age old problem that you'll find in every programming language: no matter how good a programming language is, people will find ways to write bad code in it.

And, "this practice" is something that you can't avoid given the choices of (i) static vs. dynamic and (ii) strong vs. weak typing that R has taken. If you're interested in arguing the pros and cons of each, you can find endless debates about this elsewhere on the internet that you can contribute to.

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

So we can agree that a package that relies on the user to read its function code vs. having its implementation follow what is described in its documentation needs to be improved.

You can do you part to help by emailing the author of the library to let them know about the corner case you found.

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

That's unfortunate. Can you please let us know which ones have caused you trouble so we can help get the author's attention?

Thanks,
-steve

--
Steve Lianoglou
Graduate Student: Computational Systems Biology
  |  Memorial Sloan-Kettering Cancer Center
  |  Weill Medical College of Cornell University
Contact Info: http://cbio.mskcc.org/~lianos/contact