On Wednesday, November 17, 2004, 8:14:47 PM, Jeff wrote:


> Why not a function like ....  #breakpoint?   ?

> That would then look very much like an assert.

> b = 5
> breakpoint? b == 5 ? false : true

> Yes/No? I kinda like the question syntax of it.... like should I break?

Well, I think

  breakpoint unless b == 5

is clearer.  But that's missing the point.  Any special method should
have some value over the above statement.  Like

  breakpoint_unless 'b == 5'

Would be able to use the string 'b == 5' both to test the condition
with eval and to print a message in the console explaining why the
break has occurred.

That is undoubtedly useful functionality.  The question is: what
method name is most acceptable?  'breakpoint_unless' is a bit long (I
don't care, but others probably do).  Florian likes 'assume' but I
think that's unclear -- at least it's not clear that it concerns
breakpoints.  Also I don't like to introduce too many different method
names to the global namespace.

So I thought of introducing a module, giving us

  Breakpoint.bp_unless
  Breakpoint.bp_if
  Breakpoint.bp_trap   # for trapping signals

and whatever other smart things people think of.  But that's not
clearly a good idea.

But your post gave me this thought:

  breakpoint? 'b != 5'     # breakpoint if b != 5

The question mark suggests "conditional breakpoint", a term we're all
used to from debuggers, I'm sure.  That might be the best idea yet.
I'm just not sure which logic to use:

  breakpoint? 'b == 5'     # breakpoint unless b == 5

or

  breakpoint? 'b == 5'     # breakpoint if b == 5

It's if vs unless.  I'll have to think about it, and would appreciate
other peoples' thoughts.

Cheers,
Gavin