Re: Simplify MI breakpoint setting

[Matt Rice <ratmice at gmail dot com>]

On Mon, Aug 31, 2009 at 10:16 PM, Vladimir
Prus<vladimir@codesourcery.com> wrote:
> On Tuesday 01 September 2009 Tom Tromey wrote:
>
>> >>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:
>>
>> Volodya> And, progressing recursively, what is the point of not exposing
>> Volodya> all the parameters of break_command_really?
>>
>> I don't actually know. ?But if I had to guess, I would say it is because
>> providing wrappers ensures you can't pass in some forms of nonsense.
>>
>> If you really want to do it, and nobody objects, then I guess I don't
>> care all that much. ?This whole API seems a bit nuts, any time you have
>> 13 arguments you should just assume you've done something wrong already.
>>
>> I do care about not exporting a function named "break_command_really"
>> though.
>
> Ok. I imagine that break_command_really can be renamed to set_breakpoint :-)
>

here are my thoughts,

I don't like how break_command_really looks for the symbol first, then
if it fails to find one and
pending breakpoints are enabled it will set a pending breakpoint, I
think it might sometimes make sense
to set a pending breakpoint even though there may be a match.

though I do think that the break_command_really behaviour is good for
the  'break command'
if we were to introduce a 'pbreak', or pending breakpoint command, I
could imagine pbreak_command_really or something calling something
named set_breakpoint, but that is not just renaming
break_command_really.

similarly, there is currently no way to do 'set multiple-symbols
pending' or all+pending,
and making 'set multiple-symbols ask' respond like this:

[0] cancel
[1] all
[2] pending

(note that you could select  (1 2) get all, and a pending
or 2 and just set a pending breakpoint.
(now you'll have to ignore all the rest of the stuff you can think of
required to make this behaviour anything but annoying)

this stuff as-is seems difficult since all the multiple-symbols stuff
predates pending breakpoints.
and there is no real API for setting them outside of a non-match
afaict, please correct me if i'm wrong.

so i think that makes me pro exposing some subset of
break_command_really, and not opposed to also exposing the stuff I
wouldn't need exposed.