Re: [patch] Add an evaluation function hook to Python breakpoints.

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Doug" == Doug Evans <dje@google.com> writes:

Tom> By "clean" I just mean that we want it not to have user-visible effects
Tom> other than the effects we intend. ÂYes, we can do it using a python
Tom> convenience function -- but the convenience function's name is visible
Tom> and in a flat namespace.

Doug> The reference to convenience functions was *not* a serious attempt at
Doug> arguing against doing something.
Doug> It was just an off the cuff comment regarding hacky solutions.

Sorry, I did not mean to imply that you meant this.
I was just listing our criteria for a solution.

Tom> Having two methods seems worse to me. ÂIt is more complicated without
Tom> any added benefits.

Doug> One thought I had was that maybe one might have a situation where it'd
Doug> be useful to run all the collect methods first, and then run all the
Doug> stop_p methods.

Could you give an example?

Doug> Plus I still like the API design of keeping data collection separate
Doug> from stop/don't-stop.

Can you say why?

I like the other way because it is simpler.  Also, I can't think of a
reason I would ever need two methods.

Doug> But don't let my $0.02 cents get in the way ... btw ...
Doug> If you *really* want to go this route, go for it.

Ok.  We can always add a second method if we find a need.

Doug> Btw, if some mutex-checker or whatever detected a condition that it
Doug> wanted to report to the user, IWBN to be able to throw an error that
Doug> some higher level construct could recognize and deal with.
Doug> Is a simple boolean result from stop_p (I'm only calling that for
Doug> clarity's sake) going to be sufficient?

I don't understand.  What higher level are you thinking of?
Could you give an example of when we would want to throw an exception
and what that would mean?

Tom