Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Thiago Jung Bauermann <bauerman@br.ibm.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC/RFA] add struct parse_context to all command functions
Date: Mon, 20 Oct 2008 19:03:00 -0000	[thread overview]
Message-ID: <1224529335.28191.14.camel@localhost.localdomain> (raw)
In-Reply-To: <20081020161614.GB6251@adacore.com>

El lun, 20-10-2008 a las 09:16 -0700, Joel Brobecker escribió:
> Har har har, I should be able to be active again soon :-)

Hooray. :-)

> So we have 3 alternatives:
> 
>   1. All command functions receive the parse_context structure.
>      Do the transition all at once.
> 
>   2. All command functions should receive the parse_context structure.
>      Do the transition gradually by introducing a set of "old_add_..."
>      functions that allow to hook command functions that have the old
>      profile.
> 
>   3. Only the command functions that needed it would be passed
>      the parse_context. Add a second set of add_... routines
>      to hook these command functions.
> 
> I am 50/50 on (1) and (3). I like (2) a little less. Long term,
> I think I prefer (1), but it's more painful in the short term.
> I don't mind taking the initial hit, but other's opinion welcome.

Is there any difference between (2) and (3) other than having the second
set of ad__... routines have a prettier name in (3) than they'd have in
(2)?

You could do (3) first and then stop there, or use it as an intermediate
step to get to (1).

THe problem with (3) is that you make the code slightly more complex by
adding an additional add_*_cmd that the GDB hacker will have to learn
about.

The advantage is that you can avoid writing functions with argument
they'll never use. I mention this because the ProjectIdeas wiki page
mentions that it's desirable to have GDB compile with -Wunused.

IMHO I prefer to use (3) and have the option of using the -Wunused later
(not that I'm stepping up to the task! :-) ).

> Perhaps it's another bikeshed discussion, in which case let me know,
> and I'll just decide on my own.

Perhaps it is. It took me a while to decide which I thought was better,
and then again I don't feel strong about either option.

>  It's just that it's such a large change
> that I want to make sure I won't screw anyone up.

Right, I'd also want input and some assurance before doing all this
work...
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center


  reply	other threads:[~2008-10-20 19:03 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-09 14:05 Joel Brobecker
2008-10-09 16:13 ` Tom Tromey
2008-10-09 22:20   ` Joel Brobecker
2008-10-20 16:16 ` Joel Brobecker
2008-10-20 19:03   ` Thiago Jung Bauermann [this message]
2008-10-21  0:47     ` Daniel Jacobowitz
2008-10-21 18:06       ` Ulrich Weigand
2008-10-21 18:18         ` Daniel Jacobowitz
2008-10-22  1:40           ` Joel Brobecker
2008-10-22 20:15             ` Tom Tromey
2008-10-22 20:36               ` Joel Brobecker
2008-10-21  1:22   ` Tom Tromey
2008-10-21  7:07     ` Joel Brobecker
2008-10-21 18:12     ` Ulrich Weigand
2008-10-21 18:58       ` Tom Tromey
2008-10-21 19:33       ` Tom Tromey
2008-10-22 18:03         ` Ulrich Weigand
2008-10-22 18:54           ` Tom Tromey
2008-10-22 22:24             ` Ulrich Weigand
2008-10-23  1:02               ` Tom Tromey
2008-10-23 19:50                 ` Ulrich Weigand
2008-10-23 21:29                   ` Tom Tromey
2008-10-24 13:01                     ` Ulrich Weigand
2008-10-25 16:05                       ` Tom Tromey
2008-10-27 17:07                       ` Tom Tromey
2008-10-28 16:27                         ` Ulrich Weigand
2008-10-28 18:17                           ` Tom Tromey
2008-10-28 20:00                             ` Ulrich Weigand
2008-10-25 16:25                     ` Joel Brobecker
2008-10-25 16:46                       ` Tom Tromey
2008-10-26 15:19                         ` Joel Brobecker
2008-10-21 18:05 ` Ulrich Weigand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1224529335.28191.14.camel@localhost.localdomain \
    --to=bauerman@br.ibm.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox