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

[David Winsemius]

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