It's a semantic thing, but you could also go with an #ensure name
But, I guess I have a question, why not just have a function that switches asserts to either raise an exception or cause an IRB session? that way you could KNOW your code isn't going to break into IRB in it's production environment, unless you specifically ask it to...
Anyways, I'd be happy with either...
# One time call to switch on irb asserts.
irb_assert true
.
.
.
assert b == 5
...
or maybe just irb_assert as the syntax for an assert that causes an IRB session ...
assert b == 5 # throws exception
irb_assert b == 5 # starts irb
It's a semantic thing, but you could also go with an #ensure name
But, I guess I have a question, why not just have a function that
switches asserts to either raise an exception or cause an IRB
session? that way you could KNOW your code isn't going to break into
IRB in it's production environment, unless you specifically ask it
to...
Problem with using assert() for the method name is that test/unit already uses it for stating what a test ought to produce. It seems likely that you will have test/unit style assert()s and breakpoint style assert()s (which I'd like to call assumptions) in the same code base.
And they are completely different things, so should not be toggled
from one to the other with a global switch. A typical test case will
have dozens or hundreds of asserts, but only one or two breakpoints.
And the breakpoints are very temporary; once you've worked out what's
going on, you remove them.
Testing and debugging are very different.
Gavin
···
On Thursday, November 18, 2004, 5:33:15 AM, Florian wrote:
Wood, Jeff wrote:
It's a semantic thing, but you could also go with an #ensure name
But, I guess I have a question, why not just have a function that
switches asserts to either raise an exception or cause an IRB
session? that way you could KNOW your code isn't going to break into
IRB in it's production environment, unless you specifically ask it
to...
Problem with using assert() for the method name is that test/unit
already uses it for stating what a test ought to produce. It seems
likely that you will have test/unit style assert()s and breakpoint style
assert()s (which I'd like to call assumptions) in the same code base.
I suppose that assert() can still be used. The new
version would I have to figure out that it runs in
the context of test/unit. In that context its behavior
would be compatible with test/unit.
The other contexts that assert() should support are:
- production => throw an exception
- debugging => start an irb session
- custom => invoke some user provided assert failure handler
My 2 Euro cents,
Yours,
JeanHuguesRobert
···
At 03:33 18/11/2004 +0900, you wrote:
Wood, Jeff wrote:
It's a semantic thing, but you could also go with an #ensure name
But, I guess I have a question, why not just have a function that
switches asserts to either raise an exception or cause an IRB
session? that way you could KNOW your code isn't going to break into
IRB in it's production environment, unless you specifically ask it
to...
Problem with using assert() for the method name is that test/unit already uses it for stating what a test ought to produce. It seems likely that you will have test/unit style assert()s and breakpoint style assert()s (which I'd like to call assumptions) in the same code base.
-------------------------------------------------------------------------
Web: @jhr is virteal, virtually real
Phone: +33 (0) 4 92 27 74 17
Problem with using assert() for the method name is that test/unit already uses it for stating what a test ought to produce. It seems likely that you will have test/unit style assert()s and breakpoint style
assert()s (which I'd like to call assumptions) in the same code base.
And they are completely different things, so should not be toggled
from one to the other with a global switch. A typical test case will
have dozens or hundreds of asserts, but only one or two breakpoints.
And the breakpoints are very temporary; once you've worked out what's
going on, you remove them.
Testing and debugging are very different.
I agree with you here though I think it can still make sense to toggle between different implementations of assume(). For example it might be a good idea to log the failed assumption into a warning log file for production applications and so on.
I too don't feel like assert() and breakpoint() are interchangeable.
However, I do feel like assert failure leading to the same effect
as breakpoint() is a good thing, when debugging.
Yours,
JeanHuguesRobert
···
At 07:44 18/11/2004 +0900, you wrote:
On Thursday, November 18, 2004, 5:33:15 AM, Florian wrote:
Wood, Jeff wrote:
It's a semantic thing, but you could also go with an #ensure name
But, I guess I have a question, why not just have a function that
switches asserts to either raise an exception or cause an IRB
session? that way you could KNOW your code isn't going to break into
IRB in it's production environment, unless you specifically ask it
to...
Problem with using assert() for the method name is that test/unit
already uses it for stating what a test ought to produce. It seems
likely that you will have test/unit style assert()s and breakpoint style
assert()s (which I'd like to call assumptions) in the same code base.
And they are completely different things, so should not be toggled
from one to the other with a global switch. A typical test case will
have dozens or hundreds of asserts, but only one or two breakpoints.
And the breakpoints are very temporary; once you've worked out what's
going on, you remove them.
Problem with using assert() for the method name is that test/unit
already uses it for stating what a test ought to produce. It seems
likely that you will have test/unit style assert()s and breakpoint
style assert()s (which I'd like to call assumptions) in the same
code base.
I suppose that assert() can still be used. The new version would I
have to figure out that it runs in the context of test/unit. In that
context its behavior would be compatible with test/unit.
The other contexts that assert() should support are: - production =>
throw an exception - debugging => start an irb session - custom
=> invoke some user provided assert failure handler
This is an interesting idea. I think I will try it out.
I suppose that assert() can still be used. The new
version would I have to figure out that it runs in
the context of test/unit. In that context its behavior
would be compatible with test/unit.
The other contexts that assert() should support are:
- production => throw an exception
- debugging => start an irb session
- custom => invoke some user provided assert failure handler
That it can make sense is one thing, but delivering an API that makes
sense is another 10 different people would want assume() to do 6
different things in 3 different contexts. Trying to account for all
that seems futile.
Hopefully people can use the available software to do the things they
want to do (if it's logging in production, breakpoints in testing, or
whatever). If they can't, they can suggest improvements.
Gavin
···
On Thursday, November 18, 2004, 11:53:15 AM, Florian wrote:
Gavin Sinclair wrote:
Problem with using assert() for the method name is that test/unit
already uses it for stating what a test ought to produce. It seems
likely that you will have test/unit style assert()s and breakpoint style
assert()s (which I'd like to call assumptions) in the same code base.
And they are completely different things, so should not be toggled
from one to the other with a global switch. A typical test case will
have dozens or hundreds of asserts, but only one or two breakpoints.
And the breakpoints are very temporary; once you've worked out what's
going on, you remove them.
Testing and debugging are very different.
I agree with you here though I think it can still make sense to toggle
between different implementations of assume(). For example it might be a
good idea to log the failed assumption into a warning log file for
production applications and so on.
This is a good idea to an extent. I doubt how much it would be used
in practice. To me, the use-cases for production and debugging are so
different that the same code can't serve them both.
Anyway, this kind of functionality is the responsibility of an
Assumptions framework. (To avoid clasing with Test::Unit::Assertions.)
require 'assumptions'
Assumptions.configure do |a|
a.in_debug { start_irb }
a.in_production { throw_exception }
a.custom { ... }
end
Assumptions.current_mode = :debug
...
customers.each do |c|
assume c.full_name == [c.first_name, c.last_name].join(' ')
end
What I'm saying is that this functionality can't reasonably be built
into a single method ("assert") and distributed. The above code is,
to my mind, as simple as possible, but no simpler.
Why not create something like this called Assumptions? Then use the
top-level "assume" method everywhere. If it's good, I'll include it
in dev-utils, because it's obviously a good fit. But I have no
interest in creating it myself: it sounds a lot more useful in theory
than in practice.
Cheers,
Gavin
···
On Sunday, November 21, 2004, 3:48:08 PM, itsme213 wrote:
I suppose that assert() can still be used. The new
version would I have to figure out that it runs in
the context of test/unit. In that context its behavior
would be compatible with test/unit.
The other contexts that assert() should support are:
- production => throw an exception
- debugging => start an irb session
- custom => invoke some user provided assert failure handler
The other contexts that assert() should support are:
- production => throw an exception
- debugging => start an irb session
- custom => invoke some user provided assert failure handler
I like this the best of all I've seen so far.
This is a good idea to an extent. I doubt how much it would be used
in practice. To me, the use-cases for production and debugging are
so different that the same code can't serve them both.
[...]
require 'assumptions'
Assumptions.configure do |a|
a.in_debug { start_irb }
a.in_production { throw_exception }
a.custom { ... }
end
Assumptions.current_mode = :debug
[...]
Why not create something like this called Assumptions? Then use the
top-level "assume" method everywhere. If it's good, I'll include it
in dev-utils, because it's obviously a good fit. But I have no
interest in creating it myself: it sounds a lot more useful in
theory than in practice.
I doubt I would ever use this. If I want production code throwing
exceptions, I will either explicitly code the call to raise with an
appropriate exception class or let the built in class do it (array
bounds, etc.). I wouldn't want generic "assertion failed" exceptions
being thrown.
···
On Sunday, November 21, 2004, 3:48:08 PM, itsme213 wrote:
10 different people would want assume() to do 6