Aaron Bannert wrote:
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?
In practical terms, there's almost nothing that will keep people from using old binaries with a new libapr, short of intentionally changing the name of some commonly called function to ensure that the run-time linker fails.
Changing the type name won't help, as we've discussed before, so I don't think that the binary compatibility issues are a legitimate tie-breaker for choosing the new type name.
--Brian
