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

Add explicitly named static factories to Stopwatch instead of the ambiguous ctor #1307

Closed
gissuebot opened this issue Oct 31, 2014 · 9 comments
Assignees
Labels
Milestone

Comments

@gissuebot
Copy link

Original issue created by kak@google.com on 2013-02-26 at 09:23 PM


How about we deprecate the constructor and then add two static creation methods named something like "newUnstartedInstance()" and "newStartedInstance()"?

This cleanup would be a little hairy, and the names aren't quite perfect, but maybe it's worth doing? At least Stopwatch is still @Beta.

(Note we can't just throw an ISE when calling methods on a non-started stopwatch since there are several use-cases where you'd expect a non-started stopwatch to return 0 for elapsedMillis())

Let's discuss further at API review.

@gissuebot
Copy link
Author

Original comment posted by dharkness on 2013-03-18 at 12:50 AM


There are two constructors in the master branch: one that takes a ticker and the other that specifies the system ticker. Both of these create an unstarted Stopwatch. Are you proposing to remove the ability to specify our own ticker?

@gissuebot
Copy link
Author

Original comment posted by kurt.kluever on 2013-03-18 at 04:16 AM


@dharkness: Nope...we'd remove the 2 constructors and add 4 static factory methods:

public static Stopwatch newStartedInstance() { ... }
public static Stopwatch newStartedInstance(Ticker ticker) { ... }
public static Stopwatch newUnstartedInstance() { ... }
public static Stopwatch newUnstartedInstance(Ticker ticker) { ... }

@gissuebot
Copy link
Author

Original comment posted by kevinb@google.com on 2013-03-18 at 02:15 PM


We're looking for feedback from users on whether this change is seen as worth the hassle of fixing all your existing "new Stopwatch()" calls.

@gissuebot
Copy link
Author

Original comment posted by joe.j.kearney on 2013-03-19 at 08:43 AM


I for one think that it's worth fixing. In my codebase it'll be largely a find-replace for the started ones. Definitely a clarity win.

@gissuebot
Copy link
Author

Original comment posted by stephan202 on 2013-03-19 at 09:03 AM


Agreed with #4.

@gissuebot
Copy link
Author

Original comment posted by kak@google.com on 2013-03-19 at 08:05 PM


Great, thanks for the feedback Stephen + Joe. I've just put up a G+ post about this topic, so we'll see what everyone thinks:
https://plus.google.com/118010414872916542489/posts/8XeVCd7iKxo

@gissuebot
Copy link
Author

Original comment posted by kak@google.com on 2013-03-20 at 09:28 PM


I think I'll push for Stopwatch.createStarted() and createUnstarted().

Fun fact from that G+ thread: 78% of Stopwatches are started immediately after construction!


Status: Started

@gissuebot
Copy link
Author

Original comment posted by kak@google.com on 2013-03-26 at 06:35 PM


OK, we've decided to add Stopwatch.createStarted() and createUnstarted() and then ultimately deprecate and remove the Stopwatch constructors! Thanks everyone for the valuable discussions :-)


Status: Fixed
Labels: Milestone-Release15

@gissuebot
Copy link
Author

Original comment posted by dharkness on 2014-01-20 at 11:11 PM


I'm late to the party but +1 nonetheless!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants