From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2484 invoked by alias); 6 Jan 2006 12:29:20 -0000 Received: (qmail 2474 invoked by uid 22791); 6 Jan 2006 12:29:20 -0000 X-Spam-Check-By: sourceware.org Received: from host217-40-213-68.in-addr.btopenworld.com (HELO SERRANO.CAM.ARTIMI.COM) (217.40.213.68) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jan 2006 12:29:19 +0000 Received: from espanola ([192.168.1.110]) by SERRANO.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jan 2006 12:29:16 +0000 From: "Dave Korn" To: "'Eli Zaretskii'" Cc: , , , , , Subject: RE: Return to Reverse Execution Date: Fri, 06 Jan 2006 12:29:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: Message-ID: Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00036.txt.bz2 Eli Zaretskii wrote: >> From: "Dave Korn" >> Cc: , >> , >> , >> , >> >> Date: Fri, 6 Jan 2006 10:30:40 -0000 >> >> I think that if there is any potential confusion about what the terms >> might mean in the context of having set the exec-direction reverse, then >> that simply implies that the exec-direction command is superfluous and >> obfuscating, and that all we need are one set of commands to go >> forwards, one set to go back, and people can use the correct ones >> according to the direction they actually want to go > > The main issue is not about the value of exec-direction, it is how to > call the commands that go backwards. I suggested the prefix ``back'' > or ``backwards'' instead of ``reverse''. We're about to start going in circles here :-( I _know_ you suggested a different prefix. And the reason *why* you suggested it, according to how I read your post, is because the meaning of "reverse" would be unclear as to whether it always meant the backwards direction, or whether it would swap directions if the exec-direction flag swapped value, and you are concerned that this might be a source of confusion, and you feel that the particular naming scheme you suggest would clear up the confusion. Which is why my response was to suggest that if there was no flag, there would be no ambiguity, at which point the naming would be non-confusing no matter which option was chosen, or even both. And my argument for removing the flag was that it not just eliminates this possible confusion thereby allowing us more flexibility in the command-naming scheme, but also that the flag adds no extra functionality in any case, and therefore we could do quite well without it. Because I believe the *main* issue should not be finicky details of command-naming conventions, but the serious structural issues of implementation and internals design. I don't understand why you reply just to reiterate your point, without responding or reacting to my analysis. ISTM that eliminating the confusion should have been a reasonable way to address your worries by *both* avoiding any possible confusion *and* still allowing us to have both sets of command-naming schemes as aliases. cheers, DaveK -- Can't think of a witty .sigline today....