RE: Return to Reverse Execution

["Dave Korn" <dave dot korn at artimi dot com>]

Eli Zaretskii wrote:
>> From: "Dave Korn" <dave.korn@artimi.com>
>> Cc: <gdb@sources.redhat.com>,
>> 	<jrydberg@virtutech.com>,
>> 	<fche@redhat.com>,
>> 	<brolley@redhat.com>,
>> 	<ebachalo@redhat.com>
>> 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....