Use data.table subsetting to avoid copy of large objects

[MichaelChirico]

Closes #179

This also includes #178 since it's logically related and I noticed the former while working on this.

Since I'm working on a fork I don't know of a way to make the diff cleaner (usually I'd put the merge target as #178, but that would only work as a PR to my fork).

[flying-sheep]

Hi, thanks! Does a S3 method have to be exported in order to exist? I’d prefer not to add a public API that’s unrelated to repr’s purpose!

[MichaelChirico]

I guess it depends on what you mean by "exported" -- as you see in the NAMESPACE, we've registered an S3 method, so in some sense that's "public+exported".

OTOH:

• partition_from_parts is not exported. I think that means downstreams also can't define their own S3 methods for this function, though I'm not sure (and not sure anyone would want that anyway)
• repr::partition_from_parts, repr::partition_from_parts.data.table, etc., will not work, as these functions are not exported. ::: would be needed.

I think the approach I took here is natural; depending on your concerns, we could also fake S3 dispatch ourselves and keep everything private like:

partition_from_parts = function(...) {
  if (inherits(., "data.table")) return(partition_from_parts.data.table(...))
  partition_from_parts.default(...)
}

[flying-sheep]

Ah, I see, there’s a separate export(...) for actually exported functions, sorry for the confusion!

Looks like R CMD check is complaining. Could you take care of that please?

[MichaelChirico]

Yea, a very unfortunate feature of {roxygen2} that the same @export is used for S3 method registration as for public function export :\

[flying-sheep]

Great, thank you!