On Wed, Apr 11, 2012 at 2:30 AM, Aristotle Pagaltzis <pagalt...@gmx.de>wrote:
> * Mike Doherty <dohe...@cs.dal.ca> [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
