Re: Revert use_ok() change to allow lexical effects?

On Wed, Apr 11, 2012 at 2:30 AM, Aristotle Pagaltzis <[email protected]>wrote:

> * Mike Doherty <[email protected]> [2012-04-11 01:10]:
> > 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.
>
> I don’t think changing its meaning so drastically is feasible now.
>
> Also, this leaves the issue that if it (or any other replacement of it
> with different semantics) becomes a recommended interface then the
> behaviour of `use` in lexical scope probably *should* be duplicated.
>
> But that is complexity that ideally should be shed.
>
> 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, so
> that plain `use` can be used for everything – assuming this can be done
> with less complexity than duplicating `use`.
>
> Then `use_ok` would just completely deprecated.
>
> But it’ll take a while for the entire CPAN to move off of it, so it
> can’t be deprecated too aggressively. However if it doesn’t make any
> noise, then shedding it will never happen.
>
> So maybe announce the deprecation during one perl release cycle and then
> add a once-per-testsuite warning in the next?
>

  Two questions:

* How would you rewrite a test script such as my own
http://cpansearch.perl.org/src/EBHANSSEN/Test-Trap-v0.2.2/t/00-load.t so
that it does not use use_ok()?
* Why would you? :-\

  (Sure, most of those could be just require_ok, but some would need to be
require_ok + import.  Why should I care?  I just want to know what breaks
when something's so badly broken that loading fails ... so in order to make
maintainence simpler, I'd just test require_ok + import for all of them.
At that point, I'd probably write a function that did both require_ok and
import ... now, what to call it ... oh.)


Eirik