Re: [patch] [python] Implement stop_p for gdb.Breakpoint

[Doug Evans <dje@google.com>]

On Mon, Mar 7, 2011 at 12:48 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Doug" == Doug Evans <dje@google.com> writes:
>
> Doug> - "consistency is good", so if we go with _p for stop_p we need to go
> Doug> with _p for all predicates
> Doug>   - are we prepared for that?
> Doug>   - are there any existing predicates that don't have _p?
> Doug>   - does python have an existing convention?
> Doug>   [I used stop_p at the time for clarity's sake.  But I think these
> Doug> questions need to be asked.]
>
> I don't think we should use _p on predicates.  That is not a Python
> convention.

"works for me"

> Doug> - is the logic for deciding whether to stop correct?
> Doug>   E.g. if stop_p says "don't stop" and a condition says "stop" will
> Doug> execution continue?  It looks like it, but maybe I'm misunderstanding
> Doug> something.
>
> Phil> The case of the user having an old-style GDB condition, and an
> Phil> implementation of a "stop_p" is an odd one. I was inclined to disallow
> Phil> it, but eventually decided against it.  There will be conflict if stop_p
> Phil> and condition disagree.  My first thoughts are "stop" should always
> Phil> trump "don't stop". What do you think?
>
> My view is that the conditions should be separate, and that if either
> one indicates "stop", then the breakpoint should stop.
>
> My reason is that the Python method is an implementation detail of some
> kind of "stop point" provided by a Python script.  It is not readily
> mutable by the user.  On the other hand, the condition is something
> explicitly under the user's control.

That sounds a bit weird.
The python method is part of an API.
APIs are not implementation details.

> If we really need to let the Python programmer prevent users from
> setting a condition on one of these breakpoints, we can provide a
> mechanism for doing that.

From my point of view it's not about letting the Python programmer
prevent users from ...
It's about us preventing/prohibiting a breakpoint from having both (at
least for now).

> Doug> For things like this I like to start slow: "It's easier to relax
> Doug> restrictions than it is to impose them after the fact."
>
> Doug> So my vote would be to not support both in the first pass.  It
> Doug> kinda makes intuitive sense too (to me anyway).  i.e. the default
> Doug> implementation of "stop_p" uses the command-line condition, and if
> Doug> overridden then uses the python-provided addition.
>
> These two statements are contradictory.  Or, maybe I didn't understand
> one of them.
>
> If we unify stop_p and the user condition now, it will be hard to
> separate them later -- because we will have documented that this is how
> they work.
>
> I think the most conservative approach is to make it an error for the
> user to set a condition on a breakpoint that has a stop_p method, and
> vice versa.  That preserves the ability to make a different decision
> later.

That's what I'd do.  I don't see the contradiction.
[Remember I'm talking about an *intuitive* sense here, not any literal
sense ("literal" as in something I might intend we document).
If my intuitive sense doesn't work for you, you don't have to use it.
:-)  We seem to both agree on the end result.]