From: "Piers Cawley" <[EMAIL PROTECTED]>
> Okay, there's another new branch with a bunch of changes on it,
> pdc_coderef_inner_class. Here's a quick summary of what I've done
> there.
>
> Made make_inner_class into a class method (ie expects the class it's
> called via as its first argument.) and changed all the client code to
> take this into account.
>
> Moved T::U::IC::make_inner_class to make_inner_class_with_text
>
> Created T::U::IC::make_inner_class_with_coderefs which takes a hash of
> coderefs instead of the $extension_text argument. Essentially you'd do
> something like:
>
> Test::Unit::InnerClass-make_inner_class(
> 'Test::Unit::TestCase',
> {
> test_foo => sub {...},
> test_bar => sub {...},
> },
> @args_to_constructor);
>
> I prefer this approach because then code gets compiled in a
> predictable context, which is nice. Also, because the sub {...} bits
> get compiled during the normal compilation phase, we should catch
> syntax errors and other badness much earlier.
Cool. With the text option retained for the rare cases where the
coderef approach fails, this is probably much better.
> Redid T::U::IC::make_inner_class to dispatch to the appropriate method
> depending on what gets passed in as the second argument.
>
> Rewrote some of the stuff in Test::Unit::tests::TestTest to use the
> coderef form.
Good. What do I need to check out to make the self tests work?
I checked it out with 'cvs update -d -r pdc_coderef_inner_class',
and make_test fails on two tests.
The TestRunner.pl gives (shortened output)
1) test_assert_on_failing_regex(Test::Unit::tests::TestTest)
Test::Unit::ExceptionError:
Can't locate object method "fail" via package
"Test::Unit::Assertion::Boolean" a
t lib/Test/Unit/Assertion/Boolean.pm line 16.
...
2) test_failure(Test::Unit::tests::TestTest)
Test::Unit::ExceptionError:
Can't locate object method "fail" via package
"Test::Unit::Assertion::Boolean" a
t lib/Test/Unit/Assertion/Boolean.pm line 16.
...
> Ditched $Test::Unit::InnerClass::Signpost in favour of:
>
> use vars qw/$HOW_OFTEN/;
> $HOW_OFTEN = 0 unless defined $HOW_OFTEN;
> $HOW_OFTEN++;
>
> Actually, taking this approach should mean that we can get rid of $i
> and simplify the names of the anonymous inner classes...
Not really sure about this. $HOW_OFTEN was meant to guard against
people that load the file the hard way (e.g., by reading it and then calling
eval()), while $i is needed for different extensions of one class, so they
get different package names.
In the normal "use" case, the module won't be reloaded at all due
to the "use" pragma caching loaded modules.
> I'm also in the process of looking at the CPAN module,
> Class::SelfMethods which looks of interest (but would require some
> serious rewriting to take advantage of). I'm also wondering if we
> shouldn't move T::U::InnerClass out of the Test::Unit::* namespace, it
> doesn't really belong there. We should consider spinning it off as a
> seperate module, probably called 'Class::Inner' and adding it to CPAN
> as a standalone. (And not just because it'll make for less typing when
> you want to use the package...)
I thought about this, too, several times, but I was not sure I was getting
the InnerClass stuff right enough to publish it.
Cheers,
Christian
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/perlunit-devel
