apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: cvs commit: apr STATUS
Date Thu, 11 Jul 2002 19:19:49 GMT
William A. Rowe, Jr. wrote:

> At 11:37 AM 7/11/2002, you wrote:
>
>> brianp      2002/07/11 09:37:50
>>
>>   Modified:    .        STATUS
>>   Log:
>>   Added vote on apr_time_t naming
>
>
>>          2) Renaming the function to get rid of apr_time_t vs time_t 
>> confusion,
>>             which wrowe suggests apr_butime_t [binary microtime].
>>             +1: fielding
>>             -0: wrowe
>>             -0.5: rbb
>>   +         -1: brianp [-1 for the apr_butime_t name specifically: let's
>>   +                     keep the type name independent of the internal
>>   +                     representation, so that we don't have to
>>   +                     change the name the next time we change the
>>   +                     implementation.  I'd prefer something like
>>   +                     apr_timeval_t, but I can live with apr_time_t.]
>
>
> You have a huge falacy there.  There is no way to change the definition
> without breaking binary compatibility.
>
> Since we are committed [on a go forward] to binary compatibility, this
> definition will not be changing anytime before 1.0, then before 2.0. 


I'm not worried about breaking binary compatibility; I'm
worried about breaking source compatibility.  In 2.0, if
we change the implementation, we can make it backward
compatible (at the source level, not binary) with all the
existing application code by updating the macros--unless
we have to change the type name because the 1.0 name was
tied to the old implementation.

--Brian



Mime
View raw message