Have checked in some work towards this. I don't think it's there yet, for one I think it needs to record the splitTime separately from the stopTime.
Still, any opinions would be appreciated.
Had a quick look and I have a few comments:
1) I don't really see the need for the UNSTARTED state. Start could implicitly reset if the state is STOPPED.
2) I don't see the need for separating the splitState, since I think that SPLIT_STATE is just another state. Maybe "RUNNING" should be renamed, but I don't see the overall state as 2-dimensional.
3) I agree that the splitTime *should* be split out.
4) A cleaned up version of the state diagram or a table showing start state, method, end state for all admissable method invocations should be added to the javadoc.
5) Tests, of course :-)
I can help with at least the last two items above, but I am moving a bit slowly these days (blame the heat ;-)
Phil
Hen
On Mon, 19 Jul 2004, Phil Steitz wrote:
I now understand better what split was intended to do ("current lap time" concept). I was being misled by the code :-) and the absence of a getSplitTime method.
If we want to keep it, I think it does logically lead to another state, "split" connected to "running" in the obvious way (split out, unsplit in). Both getTime and getSplitTime should be available from the split state and getSplitTime should only be available in that state.
One more thing that we should think about and at least acknowledge in the docs is the lack of synchronization. It's probably not a good idea to try to make the watch thread-safe; but we should make this explicit in the docs.
Phil
-----Original Message----- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Sun 7/18/2004 8:41 PM To: Jakarta Commons Developers List Cc: Subject: Re: [lang] Stopwatch improvements Deprecating split() is a very good point. While a real physical stopwatch has a split concept (not a stack, just a single last split time), I've never had a use for it in code.
Having played with the code a bit again, the amount of pain caused by split() far outweighs any advantage I can think of having it so I'm +1 to deprecating it in 2.1 and removing in 3.0.
Hen
On Sun, 18 Jul 2004, Phil Steitz wrote:
Steven Caswell wrote:
I think it makes sense to be able to stop from suspend. That would give the caller the most options. Otherwise, if the stopwatch were suspended, you'd have to restart it before stopping, which would change the time of the stopwatch. Being able to stop while suspended means you can stop from suspend without the time changing, but a caller could still resume and then stop if they wanted that functionality.
For reset when state is running or split, I think that should not be allowed. I think the stopwatch can only be reset if the stopwatch is stopped. That keeps the methods cleaner while still providing the necessary functionality.
I agree with both points above, but I don't think we have the states quite right. Unless the watch is going to be able to store splits, I see no value to the split state or actually the split()/unsplit() methods. Note that in the current code, stop(), split() and suspend() all do the same thing (set the stopTime to the current time). I would suggest that either split() enable actual storage of a (stack of) split(s) or it be deprecated. Could be I am missing something here. In any case, I think we can start with the simple state diagram below to model the control states of the watch.
Self-loops decorated with getTime() should appear on all three states. Self loops for split.unsplit should decorate Running. I am ambivalent on reset(). I would be OK with letting it be invoked in any of the three states (causing no state transition).
stop --------- --------- ------------> | Stopped | |Running |<------------ ^---------^ --------- start / | | | ^ / |____| | | / reset \ | / stop \_ |resume / suspend | | / v | / ------------/ | Suspended | ------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
