as.integer64 returns an error about nanotime

[eddelbuettel]

See #16, comments there welcome. Seems to work, a fresh set of eyes may help.

[joshuaulrich]

bit64 must be loaded and attached, otherwise the as.integer64 generic isn't available. If the generic isn't available, there's nothing to dispatch to the as.integer64.nanotime method. That said, you can always call the generic directly: bit64::as.integer(nt).

[restonslacker]

Given the fairly strong dependence of nanotime on bit64 (at least, that's my impression from the 'Design' section of the help page), would it make sense to load and attach bit64 by default?

[eddelbuettel]

Not sure. Depends is sort-of frowned upon these days. I would rather keep it as it is now. We do import it though.

Suggestions for making this better or more robust, @joshuaulrich ?

[joshuaulrich]

It's a thorny issue I've discussed with Achim Z before regarding xts and zoo. To paraphrase his comments for this situation:

nanotime could re-export the generic, but then any packages depending on nanotime must decide whether to register with bit64::as.integer64 or nanotime::as.integer64. Or they have to fully export their S3 method so it would be found by either generic.

As Dirk said, using Depends is discouraged. I think it would be especially so in this case, since it's not clear that users who want nanotime are also going to want every bit (pun intended) of bit64 on their search path as well.

If you want to convert nanotime to integer64, I would ask: why? Once you answer that, we might be able to have a discussion about adding functionality to nanotime to meet that need.

[eddelbuettel]

I pretty much feel the same way -- but this was eloquently put. One really only wants explicit integer64 for debugging.

So I'd say leave as is ...

[eddelbuettel]

So ... would defining

as.integer64 <- function(...) bit64::as.integer64(...)

as a free (and exported) function greatly upset the higher powers of generic functions? Seems to work:

R> library(nanotime)     ## bit64 not loaded
R> as.integer64(nt)
integer64
[1] 1486055787633531000
R> 

and then

R> suppressMessages(library(bit64))
R> as.integer64(nt)
[1] "2017-02-02T17:16:27.633531000+00:00"
R> class(as.integer64(nt))
[1] "nanotime"  "integer64"
R> bit64::as.integer64(nt)
[1] "2017-02-02T17:16:27.633531000+00:00"
R> nanotime:::as.integer64.nanotime(nt)
integer64
[1] 1486055787633531000
R> 

so it looks like worst case I may have to try clean up one class attribute stripping call.

Edit: Tempting but does not quite work, sadly.

[eddelbuettel]

Hm, I may have stumbled on the appropriate fix:

With bit64

edd@max:~/git/nanotime(feature/issue15)$ cat issue15with.R

library(nanotime)
suppressMessages(library(bit64))

nt <- nanotime("2017-02-02T17:16:27.633531000+00:00")
print(nt)
print(as.integer64(nt))

edd@max:~/git/nanotime(feature/issue15)$ r issue15with.R
[1] "2017-02-02T17:16:27.633531000+00:00"
integer64
[1] 1486055787633531000
edd@max:~/git/nanotime(feature/issue15)$ 

Without bit64

edd@max:~/git/nanotime(feature/issue15)$ cat issue15without.R

library(nanotime)

nt <- nanotime("2017-02-02T17:16:27.633531000+00:00")
print(nt)
print(as.integer64(nt))

edd@max:~/git/nanotime(feature/issue15)$ r issue15without.R
[1] "2017-02-02T17:16:27.633531000+00:00"
integer64
[1] 1486055787633531000
edd@max:~/git/nanotime(feature/issue15)$ 

That is what we wanted, in both cases. Only change: exporting as.integer64 in NAMESPACE.

Edit: Naa, didn't quite work either.

Edit 2: Did work. Needs a re-export, and hence corresponding documentation.

edd@max:~/git/nanotime(feature/issue15)$ rcc.r
────────────────────────────────────────────────────────────────────────────────
─  using log directory ‘/tmp/file58ea309392af/nanotime.Rcheck’
─  using R version 3.3.2 (2016-10-31)
─  using platform: x86_64-pc-linux-gnu (64-bit)
─  using session charset: UTF-8
✔  checking for file ‘nanotime/DESCRIPTION’
─  checking extension type ... Package
─  this is package ‘nanotime’ version ‘0.1.1’
✔  checking package namespace information
✔  checking package dependencies
✔  checking if this is a source package
✔  checking if there is a namespace
✔  checking for executable files
✔  checking for hidden files and directories
✔  checking for portable file names
✔  checking for sufficient/correct file permissions
✔  checking whether package ‘nanotime’ can be installed
✔  checking installed package size
✔  checking package directory
✔  checking DESCRIPTION meta-information
✔  checking top-level files
✔  checking for left-over files
✔  checking index information
✔  checking package subdirectories
✔  checking R files for non-ASCII characters
✔  checking R files for syntax errors
✔  checking whether the package can be loaded
✔  checking whether the package can be loaded with stated dependencies
✔  checking whether the package can be unloaded cleanly
✔  checking whether the namespace can be loaded with stated dependencies
✔  checking whether the namespace can be unloaded cleanly
✔  checking loading without being on the library search path
✔  checking dependencies in R code
✔  checking S3 generic/method consistency
✔  checking replacement functions
✔  checking foreign function calls
✔  checking R code for possible problems
✔  checking Rd files
✔  checking Rd metadata
✔  checking Rd cross-references
✔  checking for missing documentation entries
✔  checking for code/documentation mismatches
✔  checking Rd \usage sections
✔  checking Rd contents
✔  checking for unstated dependencies in examples
✔  checking examples
✔  checking for unstated dependencies in ‘tests’
✔  checking tests
✔  checking PDF version of manual

── 0 errors ✔ | 0 warnings ✔ | 0 notes ✔
edd@max:~/git/nanotime(feature/issue15)$ r issue15with.R
[1] "2017-02-02T17:16:27.633531000+00:00"
integer64
[1] 1486055787633531000
edd@max:~/git/nanotime(feature/issue15)$ r issue15without.R
[1] "2017-02-02T17:16:27.633531000+00:00"
integer64
[1] 1486055787633531000
edd@max:~/git/nanotime(feature/issue15)$ 

[restonslacker]

To answer Josh's question on why I want to do the conversion, essentially it's serialization. I'm interfacing with a system that wants time in microseconds from the epoch so this seemed like an easy way to fold that in.

In a larger, not-my-immediate-problem, sense I feel like a function that shows up in the docs should just work or provide a better error message.