Re: [RFC] Debug Operators with GDB Python

[Siva Chandra <sivachandra at google dot com>]

On Sun, Dec 2, 2012 at 8:39 PM, Doug Evans <dje@google.com> wrote:
> I would like to not go down the operator-only path without clear knowledge that:
> - if we want to rewrite it later we can do so (e.g. gdb does a bit of
> computation to select the right operator/method to invoke.
> Intercepting as early as this patch does means we bypass that and
> would have to somehow deal with it in Python - a later
> reimplementation would then mean throwing all that away, and it's not
> clear to me it could be done so in a way that doesn't risk breaking
> someone's existing Python code)
> - a design that includes methods is excessively hard

I do not think it is excessively hard to include methods/functions. My
point is, are we gaining anything by treating operators as
methods/functions. Unless we aim to allow overloading of the Python
implementations themselves, we will any way have to bypass that
infrastructure which selects the right operator/method if a Python
implementation is found. Am I missing something here? If we are not
gaining anything, what I am suggesting is that we do this as a two
step process treating them as two separate features. But again, if we
do not want to allow Python operators to be defined for languages
other than C++, treating them as methods/functions is probably more
meaningful from the users' point of view.

> Regarding templates,
> pretty-printers for, e.g., stl vectors, already have to handle this issue.
> To me it's a solvable problem (not involving excessive effort).

The issue with templates comes when we want to "add methods to a
class/type". Since a user will specify type names using name matchers,
we will not know which explicit class/type to add methods to. Having
the ability to add methods/functions would have been ideal though, as
it would then been able to make use of the GDB infrastructure which
deals with inheritance and dynamic types.

Thanks,
Siva Chandra