Re: [PATCH] Debug Methods in GDB Python

[Doug Evans <xdje42@gmail.com>]

On Fri, Dec 13, 2013 at 11:24 AM, Siva Chandra <sivachandra@google.com> wrote:
>> On Fri, Dec 6, 2013 at 3:24 PM, Siva Chandra <sivachandra@google.com> wrote:
>> I have removed DEFAULT_DEBUG_METHOD_GROUP from the code in my latest
>> patch. However, there is one reference to it in the brief (really
>> brief!) doc change I have in the patch [1]. About grouping in
>> libstdc++, is it not doing a grouping within what is facilitated by
>> the pretty printing API?
>
> dje > Not sure I understand the question.
>
> libstdc++ pretty printers use the pretty printing API provided by GDB
> Python. So, if we are to compare debug methods API to something,
> shouldn't we be comparing with the pretty printing API? About the
> matching API provided by the debug methods API in my patch, there
> isn't anything specific at all. The users can match class name and
> method name in whatever manner they please. If they like the libstdc++
> pretty printers way, then they can do it that way.

Ah.

Note that the grouping in the pretty-printer API is because one
pretty-printer can pretty-print several objects, and the functionality
is split into two steps: the lookup object returns a separate object
which is then later used to do the printing, and the lookup can record
in the returned pretty-printer-worker object whatever state it wants.
In dm-v6 AFAICT lookup and functionality exist in the same object so
that's not possible (e.g., the DebugMethod.match method returns
True/False instead of, e.g., a debug-method-worker object).

We could, I think(!), go with debug-methods as in v6, sans method
groups, and later extend it if a more formal grouping is needed.
I wonder, though, about the match method returning True/False vs the
pretty-printer way of the lookup object returning an object that then
does the printing.
[In the debug method case the lookup method might want to return a
list if the method is overloaded.]
Unless there's a compelling reason to be different, I like
"Consistency Is Good", so that's what I'm shooting for.
[But if there is a compelling reason to be different, I'm not opposed
to being different here.]