On 2012.4.10 2:52 PM, Mike Doherty wrote:
> On 12-04-10 05:20 PM, Paul Johnson wrote:
>> On Tue, Apr 10, 2012 at 12:20:20PM -0700, Michael G Schwern wrote:
>>> 2. Should use_ok() be discouraged in the documentation?
>>
>> I'm very much in favour of this.
>
> I don't see any discouragement in the documentation...
We're discussing adding that discouragement.
> and what's wrong with use_ok to begin with?
That was the second half of my post. It's a lot of extra work for a version
of this that doesn't work quite right...
use Foo::Bar;
pass "Loaded Foo::Bar";
And the pass() is just informational. If Foo::Bar fails to load the test dies
which is a failure.
> I typically use_ok(...) or BAIL_OUT. If that's the only way to use
> use_ok safely, then maybe it should do that for you automatically.
It cannot be a bail out, because there's nothing which says the module being
loaded is THE CRITICAL MODULE on which the whole test suite hangs.
It could die, but that introduces even more compatibility issues than the
lexical change. And it still leaves the problem of having to remember to wrap
it in a BEGIN block for it to truly emulate use properly.
Aristotle Pagaltzis said pagalt...@gmx.de
> I think the ideal way to handle `use` would be a `bail_on_use_failure`
> switch that intercepts `use` errors and turns them into BAIL_OUT,
Implementing this involves putting in a $SIG{__DIE__} and all the fun that
entails. Test::Builder got rid of its $SIG{__DIE__} to avoid interfering with
other code.
And it cannot be a bail out for the reasons above.
> Then `use_ok` would just completely deprecated.
I don't think it needs to be deprecated in the "issue a warning" sense. It's
not actively harmful to use, if its working for you go ahead and use it, it's
just kinda useless and not worth the effort of maintaining. I don't think
it's worth the effort to change all the hojillions of test suites that use it.
Documentation and a decision not to add more features should be enough.
--
ROCKS FALL! EVERYONE DIES!
http://www.somethingpositive.net/sp05032002.shtml
