--- Andy Lester <[EMAIL PROTECTED]> wrote: > I would just ask that it be done as > > plan tests => $n, @list_of_conditions_to_be_met > > I would hate to see the 3rd+ parms turn into a meta-language of stuff > like > > plan tests => 14, needs => "Apache::Wango 1.14"; > > Rather, just make it "everything after must be true": > > plan tests => 14, have( "Foo::Wango" ), moon_phase eq "waning", > etc;
This sounds quite reasonable, but one question: is there any chance that we might need additional information? Now we're assuming the meaning of those extra items will never change. How many times have C programmers been bitten with having a function return "negative error codes" and subsequently needed a legitimate negative return value? And plenty of people still get annoyed at having spurious pseudo-hash warnings caused by the first element of their arrayref being a hashref. Overloading the meaning of something while assuming it will never change because we can't think of a reason why it would change is dangerous. However, it's perfectly OK to overload the arguments to a function, so we could do: plan tests => 14; And with "skip all" integration: plan tests => [14, have( "Foo::Wango" ), moon_phase eq "waning"]; I realize that some will object to those two extra characters, but I'm leery of the arguments three years down the road when someone points out that "plan" doesn't allow for new features associated with TAP. Cheers, Ovid ===== Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
