Re: cvs commit: apr STATUS

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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.

So whatever we do, it will be quite stable.  But I vote on the apr_time_t
side, so it makes no nevermind here :)

Bill

Re: cvs commit: apr STATUS

[Brian Pane <br...@apache.org>]

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