> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] > > At 07:22 PM 7/11/2002, Ryan Bloom wrote: > > > From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] > > > At 07:34 PM 7/11/2002, Justin Erenkrantz wrote: > > > > > > >Not quite opaque in that you can still compute deltas via a > > > >subtraction, but that to understand the quantities, you must place > > > >it through a function/macro. Brian has already converted httpd > > > >to this model. -- justin > > > > > > OK... after much hand waving today... #apr channel folks have come > > > up with an interesting idea that might make all happy. > > > > > > IF we adopt apr_butime_t to represent a time (epoch 1.1.1970) and > > > also adopt apr_busec_t to represent any interval, timeout or other > > > delta (not rooted to an epoch) ... both declared as 64bit values, > >would > > > that satisfy everyone? > > > >No. The interval time needs to be called out as interval time, or you > >haven't solved the problem that type was intended to solve. Second, the > >names are still horrible, I REALLY hate the busec in the name, because I > >don't think _time_ when I see busec. > > Then how about apr_buseconds_t? This makes it absolutely clear that the > type contains some number of buseconds [whatever those are... open the > doxygen pages... ah... +/-number of binary microseconds.] But the fact > is the type is clearly some number of seconds, therefore an interval.
Some number of seconds does NOT indicate an interval. Also, why is that in seconds all of a sudden? Our current apr_interval_time_t are in usecs. Can we start this conversation over completely? Currently we are arguing over names for a new type, but I don't think we actually know the problem that we are trying to solve. If it is just performance, then keep the current name. Add a versioning component to APR, and force people to look at their code by using the versioning component. If it is confusion with time_t, then IMNSHO, that is a bogus argument. The bugs that were in Apache were there because nobody ever looked at the code, it was just assumed that it was correct. Anybody writing code from scratch shouldn't have the problem. If we honestly think that this is a problem, then leave change the name, but use a name that doesn't denote the implementation. http://machaut.uchicago.edu/cgi-bin/ROGET.sh.old?word=time is a list of synonyms for the word time, choose one of those. My personal preference is apr_duration_t, but I really don't like apr_busec_t. Ryan
