You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Heya, I'm just beginning to use go-whisper, and I'm wondering if it would make sense to switch a lot of function's time parameters over to using int64?
Time.Unix seems to drive most of the code I'm writing (just like it's in most of the examples on the go-whisper readme!)... and Time.Unix returns an int64. This means my code is littered with int(t.Unix()) wrappers (and also the readme examples don't compile without that fix). Switching Update and Fetch to just use int64 themselves would seem to reduce friction.
Are there any reasons not to prefer int64? I guess someone using a different concept of "time" might find it unnecessary, that seems like the exception rather than the rule, and still doesn't seem like that case would be unduly burdened by int64.
The text was updated successfully, but these errors were encountered:
hnakamur
pushed a commit
to hnakamur/go-whisper
that referenced
this issue
Jun 3, 2020
Heya, I'm just beginning to use go-whisper, and I'm wondering if it would make sense to switch a lot of function's time parameters over to using
int64
?Time.Unix
seems to drive most of the code I'm writing (just like it's in most of the examples on the go-whisper readme!)... andTime.Unix
returns anint64
. This means my code is littered withint(t.Unix())
wrappers (and also the readme examples don't compile without that fix). SwitchingUpdate
andFetch
to just useint64
themselves would seem to reduce friction.Are there any reasons not to prefer int64? I guess someone using a different concept of "time" might find it unnecessary, that seems like the exception rather than the rule, and still doesn't seem like that case would be unduly burdened by int64.
The text was updated successfully, but these errors were encountered: