Fergal Daly wrote:
> On 11/03/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
>> Fergal Daly wrote:
>> > You're suggesting that each call to extend the plan verifies that the
>> > previous plan has been executed fully? That does not allow nesting.
>>
>> Yes, nesting is what this proposal does which cannot be done now.
>
> Groups without nesting gives me subroutines with a max stack of depth
> of 1. It's almost more annoying than it is useful.
Subroutines? I don't know if I follow. Do you mean...
sub foo {
extend(2);
pass();
bar();
pass();
}
sub bar {
extend(3);
pass();
pass();
pass();
}
I believe that can be made to work without a TAP extension. Its the
producer which does the stack watching and generates the errors instead of
the TAP parser.
>> Unfortuantely the other thing it does well is shatter backwards
>> compatibility so I'd like it to do something significantly more.
>
> How does it do this? I understand that an old harness will not be able
> to parse it - it will be upset by the sub-plans and the dotted test
> numbers)
Yep. By "backwards compatible" I mean you can feed the new TAP to an old
harness and it will still be able to get the basic pass/fail information out
of it.
> but if we know we're running under an old harness then we can
> just fall back to plan-at-the-end and diagnostics.
Currently old harnesses do not identify what version of TAP they understand.
We don't even HAVE TAP versions yet. If we have to upgrade them all...
well then they'd be new harnesses. So I'd like to avoid breaking TAP
compatibility without a very good reason which is why I'm giving so much
pushback and searching for ways to do it with the TAP producer.
It would also be nice if the child plans didn't have to coordinate with the
parent plan. This would provide truly isolated nested plans. This would be
handy if you had a test which, for example, ran other tests in wholly
separate processes.
> This brings up something else. Future harnesses should probably set
>
> I_UNDERSTAND_TAP_VERSIONS="1,5,8,10-22"
>
> so we know what we can output. If that's not set then we need to stick
> to plainest TAP.
That's a good idea.
Whether or not you can set a list of specific versions (considering them as
extensions rather than increasing versions) or just a single highest version
is up for debate.
