Piers Cawley ([EMAIL PROTECTED]) wrote:
> Adam Spiers <[EMAIL PROTECTED]> writes:
> > Any chance you could knock that up? I have several patches of my own
> > which I'm struggling with to get into a commitable form.
>
> I'll get on it.
Cool, thanks. I'm very much looking forward to getting this stuff
merged. Also, the later we leave it, the harder merging gets. There
are already commits to HEAD which are in danger of getting reverted
accidentally during a merge.
> > Even if fixture generation takes place within the same test_method as
> > the assertion?
>
> Err... What are you talking about?
I know that feeling too ;-)
> If you mean
>
> $self->assert(sub {#generate_fixture;
> test_something || die "message"
> }, ...)
>
> Then, yes, it's going to be hard to distinguish between the fixture
> failure and the assert failure, but if you mean:
>
> sub test_foo {
> make_fixture; # Could die
> $self->assert(\&coderef, ...);
> }
>
> Then, I would assume that you're going to get either $@ that isn't an
> object, or it'll generate an ExceptionError exception to throw, which
> will be distinct from the ExceptionFailure thrown by the assert.
I meant the latter. That makes sense now, thanks.
> Style. Say what you mean and all that. If you mean 'I want to run the
> import method' then use 'use'. If you mean 'I want to be sure that a
> class file has been loaded' then use 'require';
>
> > If we're really concerned about not importing anything, we can
> > always use the
> >
> > use Foo ();
> >
> > form.
>
> That still means that 'import' could get run. Which is definitely not
> doing the Right thing.
Hmm, true. I'd basically ditched the use of `require' because it
reminded me of obselete Perl4-isms, and because pretty much all modern
code I've seen does the same.
> > and what type of class file would want to export stuff anyway?
>
> A stupid one.
Precisely, which is why I didn't consider using `use' a problem. What
about the compile-time vs. run-time issues? Are there any pros/cons?
One con is maybe that perl -cw could miss syntax errors in required
modules?
> > We've done that everywhere else in the code,
>
> You've been doing it wrong everywhere else in the code then.
That was other guys ;-)
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/perlunit-devel
