You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <ba...@generationjava.com> on 2004/07/19 01:43:05 UTC
[lang] Stopwatch improvements
I've put in the suggested state for the Stopwatch class into the Bugzilla
issue: http://issues.apache.org/bugzilla/show_bug.cgi?id=29163
One major issue is that it changes the functionality of Stopwatch quite a
lot, so I suspect that it should be held back for 3.0.
Opinions very welcome, on both the state suggestion and whether it should
be held for 3.0.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] Stopwatch improvements
Posted by Henri Yandell <ba...@generationjava.com>.
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
Re: [lang] Stopwatch improvements
Posted by Phil Steitz <ph...@steitz.com>.
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
RE: [lang] Stopwatch improvements
Posted by Steven Caswell <st...@mungoknotwise.com>.
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.
Steven Caswell
Sun Certified Java Programmer
steve@mungoknotwise.com
"War is an ugly thing, but not the ugliest of things. The decayed and
degraded state of moral and patriotic feeling that thinks that nothing is
worth war is much worse. The person who has nothing for which he is willing
to fight, nothing which is more important than his own personal safety, is a
miserable creature and has no chance of being free unless made and kept so
by the exertions of better men than himself." .... John Stuart Mill.
> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Sunday, July 18, 2004 6:43 PM
> To: 'Jakarta Commons Developers List'
> Subject: [lang] Stopwatch improvements
>
>
>
> I've put in the suggested state for the Stopwatch class into
> the Bugzilla
> issue: http://issues.apache.org/bugzilla/show_bug.cgi?id=29163
>
> One major issue is that it changes the functionality of
> Stopwatch quite a lot, so I suspect that it should be held
> back for 3.0.
>
> Opinions very welcome, on both the state suggestion and
> whether it should be held for 3.0.
>
> Hen
>
>
> ---------------------------------------------------------------------
> 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