Re: glib: GTimer patch for elapsed time

[Owen Taylor <otaylor redhat com>]

Gavin Baker <gavinb antonym org> writes:

> > Isn't it a little confusing to introduce the idea of a GTimer containing
> > two different times; the current elapsed time and the total elapsed
> > time?
> 
> No, I don't think so.  You are always starting and stopping the clock; you
> just choose if you want the last interval or the total elapsed time.  I
> really think that most people will want the total elapsed time anyway.
> 
> > That's why I suggested g_timer_continue() ...  it seems to me to keep
> > model simple.
> 
> Yes... I started to do it that way, but ended up realising that the
> original interface was more natural.  Using start/stop/reset is just
> like a stopwatch, which is just what you'd expect (and is precisely the
> semantics that this patch provides).

Well, clearly it was wrong for start to reset; but that's done
with so we have to work from there. To me, adding continue() to do
what start should have done is less confusing then adding a second
elapsed time variable that behaves differently than the main one.

The second variable strikes me as being a somewhat inflexible 
interface because the question then becomes "what if I want another
total (groups of 10 events)". There is a general principle that
you should either allow 1 of something or an unlimited number of that
thing. Not 2 or 3 or 5.

>  I think having g_timer_continue() is less orthogonal than the original
> interface, and would be more confusing to the user (eg. do you do a
> continue after a reset or only after stop?).  Also, it belies the
> implementation somewhat, since it effectively exposes state to the
> user.  Client code would potentially need some logic to decide whether
> to call start if it was the first time since a reset, or continue of
> start has already been called.

It would be very simple; three primitives:

 continue
 stop
 reset

and:

 start == reset + continue

> I've tested my patch and written some client code; it looks and works
> just fine.  Simple usage where the timer is being used inside the one
> function to time a single event doesn't make much difference.  But when
> you create a timer that belongs to a window, start and stop it based on
> user events, and display the elapsed time on window updates, that's when
> you need this sort of API.

All we are adding here is convenience, since it is easy enough to
keep your own total elapsed time. API should be added when it
:

 a) Enables something that isn't otherwise possible
 b) Makes an activity significantly easier

If you are just making something marginally easier than there is the
danger that you are just obscuring what's really going on.

I'm not sure saving:

 double total = 0;
 
 for (each iteration) {
   g_timer_start (timer);

   total += g_timer_elapsed (timer);
 }

 g_print ("%g", total);

Really meets the criterion of "significantly easier". Perhaps the
right direction here is simple to do nothing?

Regards,
                                        Owen