Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

int/int64 conversions #17

Open
warpfork opened this issue Aug 4, 2015 · 0 comments
Open

int/int64 conversions #17

warpfork opened this issue Aug 4, 2015 · 0 comments

Comments

@warpfork
Copy link

warpfork commented Aug 4, 2015

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.

hnakamur pushed a commit to hnakamur/go-whisper that referenced this issue Jun 3, 2020
cmd/convert.go: should close files properly after opening it
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant