export split.data.table

[jangorecki]

It might happened that users miss that we have split method just because we exported it as a method only, and not as function directly, thus split.data.table cannot be accessed without :::.
There is no harm in exporting that.

[mattdowle]

thus split.data.table cannot be accessed without :::

that doesn't seem quite right because split(DT) dispatches to split.data.table if DT is a data.table and is the normal way to access it. It was already done properly before using S3method(split, data.table) in NAMESPACE. Exporting the method explicitly (i.e. the export(split.data.table) that was added) means that users can then call the method directly and they're not supposed to do that. They're supposed to leave it to the generic: split(DT). In this case the split() generic is in base so we're even more supposed to respect it and not bypass it. The harm in exporting methods explicitly is that they might start to diverge/become incompatible with that generic. Since when a user calls the exported split.data.table method, it's not really a method anymore, that's the method being used directly as a function. It may have come about because we export dcast.data.table. But that's because dcast is not generic in reshape2 and so if reshape2 was higher on the search path, dcast(DT) would call the reshape2 one which wouldn't do any dispatch.