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
Time-dependent units can receive Clocks as dependencies to mock the passage of time. Doing so exposes nothing about their implementation, only that they depend on the passage of time. #98 removed the need to expose the use of Timers. This issue is to remove the need to expose the use of Stopwatches. Currently quiver has FakeStopwatch for mocking stopwatches. Receiving a Stopwatch (FakeStopwatch) as a dependency, exposes even more of the implementation, specifically that you're using only a single stopwatch. A StopwatchFactory typedef would at least solve that, but it still would expose the use of Stopwatches.
If it were possible to obtain a Stopwatch from a Clock, the time-dependen unit could then just receive a Clock, and create the Stopwatch internally.
Ideally the dart:core Stopwatch impl would be backed by a Clock, see:
But until then, we will want to use the dart:core stopwatch impl in production code, and a clock-backed Stopwatch in test code. The way to handle this is polymorphism, by adding a stopwatch creation method to Clock:
Stopwatch newStopwatch();
createStopwatch could also work as a name.
It should be a method instead of a getter, since it returns a new mutable object on each invocation.
The text was updated successfully, but these errors were encountered:
Minor problem: FakeStopwatch currently is in the testing directory but Clock isn't, and most people probably don't want test code in production. Presumably, createStopwatch would create a FakeStopwatch. Part of the problem may be that FakeStopwatch has a prejudicial name. Like Clock, nothing is really "fake" about it, it's just driven by the now function it's given.
So maybe this would be a natural migration path:
Rename FakeStopwatch to something more neutral-sounding, like DelegatingStopwatch.
Move it closer to Clock so that it doesn't look like test-only code.
Time-dependent units can receive Clocks as dependencies to mock the passage of time. Doing so exposes nothing about their implementation, only that they depend on the passage of time. #98 removed the need to expose the use of Timers. This issue is to remove the need to expose the use of Stopwatches. Currently quiver has FakeStopwatch for mocking stopwatches. Receiving a Stopwatch (FakeStopwatch) as a dependency, exposes even more of the implementation, specifically that you're using only a single stopwatch. A StopwatchFactory typedef would at least solve that, but it still would expose the use of Stopwatches.
If it were possible to obtain a Stopwatch from a Clock, the time-dependen unit could then just receive a Clock, and create the Stopwatch internally.
Ideally the dart:core Stopwatch impl would be backed by a Clock, see:
https://code.google.com/p/dart/issues/detail?id=18149
But until then, we will want to use the dart:core stopwatch impl in production code, and a clock-backed Stopwatch in test code. The way to handle this is polymorphism, by adding a stopwatch creation method to Clock:
createStopwatch
could also work as a name.It should be a method instead of a getter, since it returns a new mutable object on each invocation.
The text was updated successfully, but these errors were encountered: