Re: [PATCH v2] Add a way to preserve overridden GDB commands for later invocation

[Marco Barisione <mbarisione@undo.io>]

On 1 Nov 2019, at 19:18, Tom Tromey <tom@tromey.com> wrote:
>>>>>> "Marco" == Marco Barisione <mbarisione@undo.io> writes:
> Could you say what unexpected behavioural changes you would anticipate?
> I tend to think it would be clearer if all commands were treated
> identically.
> 
> Is there some implementation difficulty doing it?  Or was it just that
> you didn't think it was useful?

I was mainly worried about changing the behaviour in ways which could be
unexpected.  For instance, an instance of gdb.Command may end up living longer
than expected.
Another thing is that a command which was written before this patch may not be
using the original implementation just because it was not possible before, so
block a further command from accessing it as well.  See the example later in
the email.

If you don't think these are problems I'm happy to simplify the code.

> In this model, if a Python command overrides a built-in command, and
> then is itself overridden, can the new command still access the
> underlying built-in command?

Let's say you override delete. Let's call the first class overriding it
DeleteCommand1 and the second DeleteCommand2.

If DeleteCommand1 didn't use preserve_when_overridden then
DeleteCommand2.invoke_overridden will just call the original delete.

If DeleteCommand1 was preserved, then DeleteCommand2.invoke_overridden
will call DeleteCommand1.invoke.  At this point DeleteCommand1 may just do
whatever it needs on its own, or call its own invoke_overridden method
which will call the original delete command.
DeleteCommand2 has not way to invoke the original delete command directly.
This is partly because I'm not sure how I would expose this in a nice way,
but mainly because I don't want commands to accidentally skip some
previous implementation by accident.  For instance, if we had an
invoke_original method, then DeleteCommand2 could call that and skip
DeleteCommand1.

> What happens in the weird case that you have a command alias X, then
> override X, and then override the thing that the original X was aliased
> to?  Will calling the overridden X do the right thing?  Really I'm
> wondering if that crashes -- maybe a counter-argument to my wish for
> generality is that aliases should not be overridden.

Oh right, aliases are treated a bit differently and I didn't think of
testing that.  I should add a test and see.


-- 
Marco Barisione