Re: [lang] Stopwatch improvements

[Phil Steitz <ph...@steitz.com>]

Henri Yandell wrote:
> 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:bayard@generationjava.com]
>>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: commons-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org