apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: more notes on the apr_time_t issue
Date Sat, 13 Jul 2002 05:50:36 GMT
On Fri, 2002-07-12 at 22:44, Justin Erenkrantz wrote:
> On Fri, Jul 12, 2002 at 10:39:10PM -0700, Brian Pane wrote:
> > 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
> As Roy pointed out, this is partial hiding.  I'm now of the mind
> that it should be a full ADT under an abstract type.  Therefore,
> the +/- operations should be handled by an API.  (For performance
> reasons, it can be a macro - say apr_time_add/apr_time_diff which
> do the obvious C scalar operations.)  But, under no circumstances
> for this solution, can the user do *anything* with the value
> without going through some API.

Agreed.  And that API includes:
    type_name_tbd operator+(type_name_tbd a, type_name_tbd b);
    type_name_tbd operator-(type_name_tbd a, type_name_tbd b);

> If that bugs you (and it well might), then we need to go the
> apr_busec_t route and rename every APR time function.  -- justin

-1 for renaming any APR time functions: just rename the data type.


View raw message