Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 8 Jul 2002 01:20:24 -0700
From: Aaron Bannert <aaron@clove.org>
To: dev@apr.apache.org
Subject: Re: next steps for changing apr_time_t?
Message-ID: <20020708012024.M1936@clove.org>
Mail-Followup-To: Aaron Bannert <aaron@clove.org>, dev@apr.apache.org
References: <1026114367.1420.13.camel@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1026114367.1420.13.camel@localhost>
User-Agent: Mutt/1.3.23i

On Mon, Jul 08, 2002 at 12:46:04AM -0700, Brian Pane wrote:
>     How much will this impact other APR-based apps (SVN, Flood, etc),
>     and is now a good time to break things?
> 
>     Should the new data type still be called apr_time_t?  (My own
>     preference is to change the name so that existing applications
>     will break predictably at compile time rather than unpredictably
>     at run time.)

I am strongly opposed to reusing the apr_time_t identifier. In my mind,
we should do the two things separately: 1) create and start using
binary usecs, and 2) decide* how to deprecate the apr_time_t interface.

*This is all a matter of how nice we want to be. I'm leaning toward
keeping the apr_time_t interface for awhile. Another good option might
be to cause some compile-time breakage that makes the change obvious.

-aaron