-
Notifications
You must be signed in to change notification settings - Fork 139
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
Use strong typing instead of ruby-like 1.seconds
#4
Comments
I would make |
@DeFrenZ That's a lot of absurd complexity for a reduction in performance and flexibility. There is literally no reason to have distinct types.
The |
Thanks for the great feedback . Let me address your points:
I agree. Unfortunately a lot of Swift libraries right now have this problem, as people want to extend the standard library with things like Result, and all sorts of FP stuff… But honestly, adding a global
This is mostly a made up problem. I like what static typing help us do, but let's not get crazy. No one's going to write I agree though that having a dedicated type for time intervals would be superior to representing them using The reason why I didn't do that here is that it feels out of scope of this project. I just wanted to make a better API for NSTimer, and helpers like
I completely disagree with that. |
But it's not global. At least, not if your code is built as its own module. Anyone who wants to use two different modules that both use a As for "how I want the official standard library to be", I very strongly disagree that |
Good point.
I honestly don't see your point. If Double#seconds et al returned some sort of a Care to elaborate why you think "2.seconds" is inferior to "Duration(seconds: 2)"? |
Two reasons:
|
Is it silly? I think it's nice.
Oh, come on. i can't imagine many contexts where someone would think "seconds" means something else than seconds...
Hmm, yeah, I could live with that. Seems like a totally reasonable compromise. |
@kballard thinking a bit about it I see your point. It is indeed the same data, just referenced in different manners. Just like I also agree that, even if it maybe looks a bit nicer and slightly easier to use, we should be extremely conservative with extending basic data types (at least when doing public libraries), even just for the sake of cluttering a common namespace. The free function does solve this problem and is still easy to use. |
Extending
Int
andDouble
with propertiessecond
,seconds
,minute
, etc. seems like a rather bad idea. There's two problems with this:NSTimeInterval
as your actual time type, and all it takes is for someone to accidentally leave off the.minutes
and they'll get the wrong time. This isn't a huge issue, asNSTimeInterval
is used everywhere to mean seconds and people are used to it, but we can still do better.The better approach is to use an actual
Duration
type that requires the user to type the unit as part of the constructor. With the ruby-like approach you can just sayNSTimer.after(1) { ... }
but with a proper strong type there's no way to do this. I'd suggest something likeThis way you can then say
NSTimer.after(Duration(seconds: 1)) { ... }
. You could also experiment with replacing all those initializers with static functions instead (e.g.static func seconds(seconds: NSTimeInterval)
) so that way you can sayNSTimer.after(.seconds(1)) { ... }
.The text was updated successfully, but these errors were encountered: