We removed it from suggests but still have some snippets like:
ns = tryCatch(getNamespace("reshape2"), error=function(e)
stop("The dcast generic in data.table has been passed a ",class(data)[1L]," (not a data.table) but the reshape2 package is not installed to process this type. Please either install reshape2 and try again, or pass a data.table to dcast instead."))
ns$dcast(data, formula, fun.aggregate = fun.aggregate, ..., margins = margins,
subset = subset, fill = fill, value.var = value.var)
I don't think it makes sense to support such functionality anymore.
Question is, are we safe to just get rid of it right away, or do we need to lifecycle it out?
The text was updated successfully, but these errors were encountered:
On Tue, May 14, 2019, 8:03 PM Jan Gorecki ***@***.***> wrote:
According to comment (probably very old one) in melt
# if data is not data.table and reshape2 is installed, this won't dispatch to reshape2's method;
# CRAN package edarf and others fail without the else branch
Question is, should we create generic methods for dcast and melt?
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
or mute the thread
By default, if any of the columns to be melted are of type factor, it'll be coerced to character type. This is to be compatible with reshape2's melt.data.frame.
Now that we're taking ownership of dcast/melt, do we want to continue this backward-compatibility?
Of course we'd have to go through a deprecation cycle, but ultimately do we agree with this behavior?
warning("To be consistent with reshape2's melt, id.vars and measure.vars are internally guessed when both are 'NULL'. All non-numeric/integer/logical type columns are considered id.vars, which in this case are columns [%s]. Consider providing at least one of 'id' or 'measure' vars in future.", CHAR(STRING_ELT(concat(dtnames, idcols), 0)));