apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject more notes on the apr_time_t issue
Date Sat, 13 Jul 2002 05:39:10 GMT
There currently are four options listed in STATUS for changing
the time representation.  There are vetoes for two of them.  The
other are:

 2) Renaming the function to get rid of apr_time_t vs time_t confusion,
    but keep it ambigious and make no contract with the user about the
    units represented.

 3) Renaming the function to get rid of apr_time_t vs time_t confusion,
    and strongly identify the type as apr_busec_t or apr_butime_t, with
    an ongoing contract with users about the type's units.

Based on all our discussions of the past few days, I believe these
two options are identical in practice.

If the new time type is an abstract type, the common operations on
it will be:
    - Native C scalar + and - operations for time arithmetic
      (for performance and simplicity reasons)
    - Macros to extract seconds and microseconds

And if it's a transparent type, the common operations will be:
    - Native C scalar + and - operations for time arithmetic
    - Macros to extract seconds and microseconds (to spare application
      programmers the complexity of doing the shifts themselves)

I.e., no matter which option we use, I anticipate that the
code surrounding these types will look exactly the same.

The only major difference remaining seems to be the naming:
apr_utime_t (and interval variants thereof) vs apr_time_busec_t
(and interval variants thereof).

Can we come to an agreement on one of these names to bring
the issue to a close?

Thanks,
--Brian



Mime
View raw message