From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13752 invoked by alias); 20 Oct 2008 16:16:54 -0000 Received: (qmail 13741 invoked by uid 22791); 20 Oct 2008 16:16:53 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 20 Oct 2008 16:16:18 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id A86F12A965F for ; Mon, 20 Oct 2008 12:16:16 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3NmyoMZjDUOu for ; Mon, 20 Oct 2008 12:16:16 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 509B62A9656 for ; Mon, 20 Oct 2008 12:16:16 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 5F8D0E7AD0; Mon, 20 Oct 2008 09:16:14 -0700 (PDT) Date: Mon, 20 Oct 2008 16:16:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: [RFC/RFA] add struct parse_context to all command functions Message-ID: <20081020161614.GB6251@adacore.com> References: <20081009140424.GD5372@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081009140424.GD5372@adacore.com> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00492.txt.bz2 Har har har, I should be able to be active again soon :-) > I'd like to start working on adding a struct parse_context again. > The ultimate goal is to pass this structure as an argument to all > the "parse..." routines, rather than rely on the current_language > and input_radix globals. In addition to being cleaner, it will also > help fix a bug where the current_language is switched under us while > trying to do parse an expression. Going back to this, Tom and I exchanged a couple of emails, and the discussion lead to an interesting suggestion. The base for the suggestion is that Tom wonders whether it might be a little excessive to push this extra argument that might actually only be used by a subset of the commands. I initially agreed, but then thought about it some more, and realized that all the command functions receive the arguments as a string, and thus can potentially parse it. So, always passing the parsing context wouldn't seem unreasonable to me either. In any case, the idea that emerged is that we could provide 2 possible command profiles, dependending on what the specific needs of the function are. The advantage is that we then only transition the command functions that need the parse context, and the transition can be done piecemeal. The issue is that we will have to duplicate all the various add_cmd functions for the new extended profile. So we have 3 alternatives: 1. All command functions receive the parse_context structure. Do the transition all at once. 2. All command functions should receive the parse_context structure. Do the transition gradually by introducing a set of "old_add_..." functions that allow to hook command functions that have the old profile. 3. Only the command functions that needed it would be passed the parse_context. Add a second set of add_... routines to hook these command functions. I am 50/50 on (1) and (3). I like (2) a little less. Long term, I think I prefer (1), but it's more painful in the short term. I don't mind taking the initial hit, but other's opinion welcome. Perhaps it's another bikeshed discussion, in which case let me know, and I'll just decide on my own. It's just that it's such a large change that I want to make sure I won't screw anyone up. -- Joel