digest method for most/all object types

[billdenney]

I'm working on nlmixr2targets, and I find that in some scenarios, I consistently get different model digest values (digest::digest(rxuiObject) differs between R sessions for rxUi objects that are created the same way). I think that this relates to creating digests of the environments or temporary files.

That said, the rxuiObject$md5 value remains consistent between R sessions.

1. Would it be reasonable to create a digest.rxUi method that would return the object$md5 value or can you think of a reason that should not be done?
2. And related to that, would it make sense to create a digest.nlmixr2FitCore method that would do the same thing?
3. Would there be any other object types that should have a digest method created?
4. Should this live in the specific packages (rxode2::digest.rxUi, nlmixr2est::digest.nlmixr2FitCore) or within nlmixr2targets?

[billdenney]

This is related to #163.

[billdenney]

@mattfidler, I was trying to trace where digest values differ when I'm creating what I think is the same object. I found in an rxUi object that the ui$mv0$timeId value differs. It appears to be some type of timestamp. Is it reasonable to ignore that when creating a digest of an rxUi object or is it important in some way for the ui object?

Edit: As I was looking at nlmixr2 fit objects, I think that the address pointer to the rxode2 object address pointer will also cause issues with digest results. Can we chat about how to work around those in the next development meeting?

[billdenney]

I think that the following would provide a stable digest method by ignoring compilation time:

sha1.rxUi <- function(object, ...) {
  rxuitmp <- object
  rxuitmp$mv0$timeId <- -1L
  digest::sha1(unclass(rxuitmp))
}

But, it may break things if assignment of -1L changes the original model.

[billdenney]

This is outside of rxode2 but related. For an nlmixr2FitData object one element that differs as well is the object$env$time data.frame which gives duration of the fit steps. That should probably be omitted from its sha1 method.