From dev-return-11997-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Mon Jun 14 15:28:58 2004 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 13184 invoked from network); 14 Jun 2004 15:28:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 14 Jun 2004 15:28:57 -0000 Received: (qmail 75370 invoked by uid 500); 14 Jun 2004 15:28:58 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 75108 invoked by uid 500); 14 Jun 2004 15:28:55 -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 74989 invoked by uid 99); 14 Jun 2004 15:28:54 -0000 Date: Mon, 14 Jun 2004 11:08:05 -0400 (EDT) From: To: Brad Nicholes cc: , Subject: Re: Q: apr_procattr_xxx() API (was: cvs commit: apr/include apr_thread_proc.h) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Mon, 14 Jun 2004, Brad Nicholes wrote: > Is there a reason why the apr_procattr APIs were implemented as > > apr_procattr_xxx_set (apr_procattr_t*, value) > > rather than > > apr_procattr_set (apr_procattr_t*, APR_xxx_ATTR, value, ...) > > It seems like the second approach would make it easier for a platform > to extent the apr_procattr_t structure without having to add a new API > each time, just to have the new API become a no-op for every other > platform. I did it that way to get type-safety for the arguments. Ryan