Make db@data printable

[patrickbarks]

Picking up from #32, I think print(db@data) throwing an error is an issue that should be solved, even if we don't want users to access the data slot that way. Presumably many users will use db@data$ to create derived columns. I think some users will realize db@data is just a data.frame, and that's where all the important stuff is, and then be confused when normal data frame stuff fails (this is exactly what happened to me). The options that I can think of (there may well be others):

1. make db@data a tibble
2. move db@data$mat back to it's own slot (db@mat)
3. make a custom class and print method for db@data
4. drop the CompadreM class and revert db@data$mat to a list of lists (that way print(db@data) won't throw an error, though the printing won't be pretty)

I think option 1 or 2 are the least worst.

[jonesor]

I think we should try the tibble approach. It seems to me to be the most straightforward, and preserves the relationship between the metadata and the matrices (which was the main advantage/reason behind putting them in the data frame in the first instance.
I guess I can just add tibble to the imports bit of the DESCRIPTION, and then set the data slot to class "tibble".

[patrickbarks]

I think it can all be done within the initialize method. The data slot can remain "data.frame" within setClass because tibbles always retain the "data.frame" class too.

#' @importFrom methods callNextMethod validObject
#' @importFrom tibble as_tibble
setMethod("initialize", "CompadreData",
    function(.Object, ...) {
        .Object <- methods::callNextMethod()
        .Object@data <- as_tibble(.Object@data)
        methods::validObject(.Object)
        .Object
    })

### then run devtools::document() and add tibble to imports

[patrickbarks]

closed by #43 and subsequent updates