On Tue, Mar 28, 2006 at 06:49:15AM -0600 Chris Dolan wrote:
> On Mar 28, 2006, at 4:55 AM, Tassilo von Parseval wrote:
>
> >>Do you think this might work better, or could be implemented as, a
> >>seperate Test::Fork type module?
> >
> >It certainly could be done. But it would essentially share 90% of its
> >code with Test::Builder.
>
> Umm, subclassing? :-)
In practice that would be the same thing. I'd have to override six
methods, including all the big ones ok(), skip(), todo_skip() and
_ending(). So I'd wind up copying their code verbatimly. Test::Builder
was evidently not written with subclassing in mind.
My patch actually addresses this en-passant as it factors out some code
into methods of its own. Those would be the very methods that would need
overriding.
> >It's simple really: Either my proposed method
> >is robust in which case it can go into Test-Simple. Or it isn't. Then
> >there's no need to implement it as a separate module. :-)
>
> I don't think it is that simple. *IF* there are any bugs in this
> niche feature, then it could break the most popular test module on
> CPAN. Clearly from your proposed patch, any code that needs the fork
> feature of Test::More says so explicitly via the $self->{Forked}
> property. So specifying a subclass instead, like a hypothetical
> Test::More::Forked, should be trivial. I have not yet seen any
> justification for adding this feature to Test::More itself.
Well, the author of Test::More seems to differ on that:
<http://rt.cpan.org/Public/Bug/Display.html?id=8391>
Cheers,
Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
