From hpages at fredhutch.org  Tue Dec  6 18:56:35 2016
From: hpages at fredhutch.org (=?UTF-8?B?SGVydsOpIFBhZ8Oocw==?=)
Date: Tue, 6 Dec 2016 09:56:35 -0800
Subject: [Rd] unlist strips date class
In-Reply-To: <F1791DAB-5420-480B-AC49-ADF672B28DB8@gmail.com>
References: <CAPekMC=Od4ib7QJbpk8iGm9woUB4bzM+5BYq3vLqH_4u9ApXNA@mail.gmail.com>
	<84139199-8a1f-28f9-2ab0-fae8cd90976b@fredhutch.org>
	<F1791DAB-5420-480B-AC49-ADF672B28DB8@gmail.com>
Message-ID: <22a90bab-1f0e-b713-4366-69bad565990c@fredhutch.org>

On 12/05/2016 01:05 AM, peter dalgaard wrote:
>
> On 02 Dec 2016, at 23:13 , Herv? Pag?s <hpages at fredhutch.org> wrote:
>
>> More generally one might reasonably expect 'unlist(x)' to be equivalent
>> to 'do.call(c, x)' on a list 'x' where all the list elements are atomic
>> vectors:
>
> Well, both are generic, and e.g. there is no "Date" method for unlist(), but there is for c(). It is not clear that the two should be kept in lockstep and there is certainly no mechanism to enforce that.

If unlist() was based on c(), or c() was based on unlist(), or
unlist() and c() were sharing more code internally, then they would
naturally be kept in lockstep and you wouldn't need any mechanism to 
enforce that.

Note that the arguments of the default S3 method for c() are:

   c(..., recursive = FALSE, use.names = TRUE)

i.e. exactly the same as unlist() (except for the default value).
This suggests that implementing one on top of the other is kind of a
natural thing to do.

H.

-- 
Herv? Pag?s

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fredhutch.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319



[Rd] unlist strips date class
=?UTF-8?B?SGVydsOpIFBhZ8Oocw==?=