Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 17934 invoked by uid 500); 14 Jul 2002 20:29:38 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 17918 invoked from network); 14 Jul 2002 20:29:37 -0000 From: "Sander Striker" To: , "'William A. Rowe, Jr.'" Cc: "'Aaron Bannert'" , Subject: RE: more notes on the apr_time_t issue Date: Sun, 14 Jul 2002 22:39:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <009c01c22b74$13faf610$0a01230a@KOJ> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > From: Ryan Bloom [mailto:rbb@covalent.net] > Sent: 14 July 2002 22:22 [...] > > >A way to compare and operate on time: > > > > > >Apr_busec_add > > >Apr_busec_sub > > > > Those are BS. This is a SCALAR. It will always remain a scalar, > > lest our performance takes a flying leap from the window. > > I may be wrong, but I explicitly remember seeing those macros being > discussed. Indeed. And can we please add them? It would save us a lot of time (heh) when we want to switch apr_time_t to yet another (source compatible!) representation. Users should be cautioned by saying we don't do guarantees unless they use the macros. That the macros are defined to be simple scalar operations (for this particular choice of implementation) doesn't matter. This is IMO all we can do, short of making apr_time_t a true ADT, which we can't for obvious reasons. Sander