From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32728 invoked by alias); 23 Oct 2003 05:06:16 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 32721 invoked from network); 23 Oct 2003 05:06:15 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 23 Oct 2003 05:06:15 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 0C16D2B89; Thu, 23 Oct 2003 01:06:14 -0400 (EDT) Message-ID: <3F9761C5.1040508@gnu.org> Date: Thu, 23 Oct 2003 05:06:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Simplify target stack References: <3F8DCC3A.4030201@redhat.com> <20031016131613.GB14202@nevyn.them.org> <3F8EB8F8.7040700@redhat.com> <20031016230710.GB1542@nevyn.them.org> <3F8F3610.2090407@gnu.org> <20031023035845.GA4655@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00688.txt.bz2 >> > Just because you can avoid doing it now doesn't mean that's OK. You >> >tell that to other developers at every opportunity. > >> >> And given a set of alternatives I'll take the one with the greatest bang >> for the buck. > > > Please don't pretend I'm the only one on this list who has asked for a > contributor to take the longer way to a goal, in light of later > cleanups. I'm not. I try to apply the `bang for the buck' rule evenly to both myself and to others. For instance, given the choice of asking JeffJ to add a new LESS_THAN_SPECIAL architecture method (+ test + doco + ...) xor just tighten comments in frame.h, I chose the latter. A full analysis of the problem revealed that the former and zero bang for the buck! > This is standard practice for keeping the code maintainable, > and evolving towards improved organization. There's a balance. Er to much towards features and code quality goes down. Er to much towards structural perfection, and new features are never added. You'll note that so far, as part of getting PPC64 linux working, I've also: fixed struct return, and elimininated the need for a redundant architecture method. > I see that you've checked this patch in despite my objections. I thought that I had clearly stated the rationale for ordering the development the way I had. That left me, as target vector maintainer, and the person willing to do the immediate work, with a judgment call. > Please > let me know when you're done with modifying the target vector for a few > days and I'll just separate instance and ops myself, including moving > the new to_beneath and to_data fields out of struct target_ops. It will be a lot more than a few days :-( And if you wait long enough, I'll likely to do it myself! Andrew