Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 86969 invoked by uid 500); 19 Sep 2001 22:10:28 -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 86950 invoked from network); 19 Sep 2001 22:10:28 -0000 Date: Wed, 19 Sep 2001 15:07:27 -0700 From: Brian Pane Subject: Re: apr_table_t (was: Re: Release time?) To: dev@apr.apache.org Message-id: <3BA9171F.4020403@pacbell.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913 References: <20010919151902.2D44646DFD@koj.rkbloom.net> <3BA8F130.7090004@pacbell.net> <20010919142804.D12417@ebuilt.com> <20010919213322.C292C46DFC@koj.rkbloom.net> <20010919143821.E12417@ebuilt.com> <04ee01c14156$535c5f00$93c0b0d0@roweclan.net> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N William A. Rowe, Jr. wrote: [...] >In the case of tables, the minimum api I would accept includes a duplicate >and truncate function. Also (of course) the existing add, as well as an >insert (since we loose the ability to do so with this change.) > Insert? For a table, insert==add, because it's an unordered collection. Similarly, the semantics of truncate would be unpredictable. >In the case of hashes, we still need an efficient duplicate. > I agree. --Brian