# from Michael G Schwern
# on Tuesday 04 December 2007 15:24:
>A. Pagaltzis wrote:
>>...
>> which would still be an error. That way a mistake in a test
>> script won’t lead to Test::More silently converting an up-front
>> plan declarations into trailing ones.
>
>Which brings us back to the original question: why should that be an
> error?
It's a matter of stricture? If the developer intended the plan to be
before-hand, they'll be expecting an error to enforce that practice.
The current planning functions impose strictures. (Yes, it happens to
be due to an old implementation detail which no longer governs -- but
that doesn't change the fact that behavior expectations have already
been set.) Taking away the error essentially means that you've changed
the API. Imagine if strict.pm suddenly stopped being strict about
symbolic refs.
That is, users should somehow be able to rely on the same strictures
that they've had in the past (hopefully by-default.) So, either this
new non-strict plan scheme should be declared in the import() params or
be not named plan().
E.g. add_to_plan() for the plan-as-you-go usage and plan_was() for
planning at the end or something.
I'm still wishing for the "plan to make it to a given statement" model
(e.g. done().)
--Eric
--
"It is impossible to make anything foolproof because fools are so
ingenious."
--Murphy's Second Corollary
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
