apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: more notes on the apr_time_t issue
Date Sun, 14 Jul 2002 20:36:37 GMT
On Sun, Jul 14, 2002 at 04:01:35PM -0400, Cliff Woolley wrote:
> And while apr_time_busec_t is a bit better than apr_utime_t, I agree
> people will say "wtf is a busec".  And it means we'd have to rename all
> our time functions for no good reason.  "apr_time_now" just makes so much
> sense.  "apr_time_t" makes so much sense.  That's just got to be it.

The whole problem here (and this is where I completely agree with you
all) is that apr_time_t is the perfect name for the time system in APR.
It's just that if we change out the implementation w/o the ability to
break at dynamic link-time, then there will be huge problems.

> How to resolve Aaron's veto?  The #ifndef NEW_TIME_FMT thing is
> interesting.  :)

How does that help me though? Wouldn't that mean that APR would be linked
with the new time implementation and the older app would link in just
fine even though the representation had changed?


View raw message