"Christian Lemburg" <[EMAIL PROTECTED]> writes:
> 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.
> ...
Weird. Both of those work here. Have you got any local changes in your
tree?
> > 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.
Indeed. However: C<$HOW_OFTEN = 0 unless defined $HOW_OFTEN> will only
get called the first time T::U::InnerClass gets loaded, and after
that, so long as each anonymous classname is unique (which it will be
because we'd increment the counter each time) then we're happy.
> > 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.
If we tidy it up a little (I'm a little unsure about the method names,
especially given that what is actually returned is an object...) then
I think it's good enough to release, people can always suggest changes
once it's out there.
--
Piers
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/perlunit-devel
