[datatable-help] Playing nice(r) with S4?

Steve Lianoglou mailinglist.honeypot at gmail.com
Wed Nov 24 17:31:26 CET 2010


Hi,

Just an update: I'm working on adding this to package.

When it's all said an done, I think we might actually have to add an
`Imports: methods` clause to the DESCRIPTION file, as well as an
`exportClass(data.table)` to the NAMESPACE.

Would that be OK?

I'm getting some strange warnings with R CMD check, so will sort that
out over the next few days when I can find the time.

Thanks,
-steve


On Tue, Nov 23, 2010 at 11:35 AM, Matthew Dowle <mdowle at mdowle.plus.com> wrote:
>
> Hi Steve,
>
> I don't know much about S4 but seems like a good idea, no objections from
> me either.
>
> Please click 'request to join' button on R-Forge project page for
> data.table, add some tests to the end of test.data.table.R, add something
> to the NEWS file, run 'R CMD build' and 'R CMD check', and (if ok) commit.
>
> Matthew
>
>
>> Hi Tom,
>>
>> On Tue, Nov 23, 2010 at 10:53 AM, Tom Short <tshort.rlists at gmail.com>
>> wrote:
>>> On Tue, Nov 23, 2010 at 10:33 AM, Steve Lianoglou
>>> <mailinglist.honeypot at gmail.com> wrote:
>>>> Hi all,
>>>>
>>>> Can we include some functions/declarations so that data.table objects
>>>> can be used in S4 classes?
>>>
>>> Steve, S4 has always scared me off, but if we can do something easy
>>> like that to help users, we probably should.
>>
>> At the start, it did for me as well, but I think I (largely) have the
>> hang of it ... I wouldn't say I'm an expert, though.
>>
>>> Do we have to require any other packages?
>>
>> Not as far as I know. Usually a package that defines S4 classes and
>> such is required to import the 'methods' package, but I'm not sure if
>> it's necessary here.
>>
>> I simply just `svn up`d my data.table repo and added the AllS4.R as
>> written above, then `R CMD INSTALL`ed it, and everything was kosher --
>> no warnings or anything and it works as expected.
>>
>>> My only comment is related to the data.table(from) in the setAs
>>> function. Do you want that to be as.data.table(from)? The latter is
>>> probably faster but does less error checking and auto-conversions of
>>> columns.
>>
>> Sure -- I'm largely indifferent on that, so whatever is more idiomatic
>> for the data.table devs probably will make the most sense.
>>
>> Maybe for consistency sake, one would add:
>>
>> setAs("data.table", "data.frame"), function(from) {
>>   as.data.frame(from) ## or whatever
>> })
>>
>> So we can go back the other way and convert a data.table back to a
>> data.frame via `as(dt, "data.frame")`
>>
>> -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
>> _______________________________________________
>> datatable-help mailing list
>> datatable-help at lists.r-forge.r-project.org
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
>>
>
>
>



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


More information about the datatable-help mailing list