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.
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]
