From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-10373-listarch-gdb=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 15069 invoked by alias); 17 Sep 2002 05:03:59 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 15057 invoked from network); 17 Sep 2002 05:03:52 -0000
Received: from unknown (HELO localhost.redhat.com) (24.112.240.27)
  by sources.redhat.com with SMTP; 17 Sep 2002 05:03:52 -0000
Received: from ges.redhat.com (localhost [127.0.0.1])
	by localhost.redhat.com (Postfix) with ESMTP
	id DE7A53D77; Tue, 17 Sep 2002 01:03:43 -0400 (EDT)
Message-ID: <3D86B7AF.2090803@ges.redhat.com>
Date: Mon, 16 Sep 2002 22:03:00 -0000
From: Andrew Cagney <ac131313@ges.redhat.com>
User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Daniel Jacobowitz <drow@mvista.com>
Cc: David Carlton <carlton@math.stanford.edu>,
	gdb <gdb@sources.redhat.com>
Subject: Re: struct environment
References: <ro1lm6gcg9r.fsf@jackfruit.Stanford.EDU> <20020906150620.GA19200@nevyn.them.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2002-09/txt/msg00216.txt.bz2

> 
> Why do you want to have multiple available implementations?  I think
> the overhead for always hashing is small enough.  There are only two
> reasons struct block allows hash tables or linked lists:
>   - overloading of the meaning of that list to represent a list of
>     function arguments, which is ordered
>   - warts in mdebugread that I was not patient enough to overcome when
>     I finally merged in hash table support
> 
> I suppose the first reason is a legitimate one for multiple
> implementations; we could mark an environment as 'ordered'.  Or we
> could stop overloading the meaning of the list that way.  I don't know
> which is better.

Daniel's observation is correct.  The last thing we need is something 
totally overengineered.  Is there any reason to not start out with a 
very simple implementation and get it working first?

Only once the structure is working correctly should we be thinking about 
making it work fast.

Andrew