Re: [python][rfc] Change gdb.Breakpoint to use attributes instead of methods.

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Thiago" == Thiago Jung Bauermann <bauerman@br.ibm.com> writes:

Thiago> Here's a patch that changes almost all of gdb.Breakpoint
Thiago> methods to attributes. Most are settable.

I like it.

The list of exceptions to the rule made me laugh a little :)
I wasn't expecting quite so many quirks.  But, I don't think it
matters ... do you?

Thiago> The setter for 'hit_count' imposes the artificial restriction that you
Thiago> can only set it to zero (to keep the semantics of the previous
Thiago> 'clear_hit_count' method. Would it be useful to lift the restriction?

Either way.  I suspect that this isn't an extremely useful attribute.

Thiago> The 'silent' attribute has a gotcha: if it is True, then it's guaranteed
Thiago> that the breakpoint will be silent. But if it's False, then it may still
Thiago> be silent if the first command associated with the breakpoint is
Thiago> "silent". This is due to the way a breakpoint is silenced (see the
Thiago> places which set bs->print to 0 in bpstat_stop_status). Again, I won't
Thiago> work on that, at least for now.

Yeah.  This is an internal quirk; I originally exposed this since I
thought it was nice to be able to silence a breakpoint without messing
around with the commands.

Thiago> The 'condition' attribute also has a gotcha: if the expression is not
Thiago> valid, an exception will be thrown but the expression will still be set
Thiago> as the condition of the breakpoint. This also happens with the
Thiago> "condition" command in the CLI, so it's an issue (or a feature?) of GDB
Thiago> itself, and not this code.

Nice catch.  We can ask on the gdb list.

Looking at the code, it seems to me that a condition could be set on
one location of a breakpoint but not on others.  That seems weird to
me.

Thiago> What do you think?

I think it is good to go.

I see that I never wrote documentation for gdb.Breakpoint.
I will do this.

Tom