From: "Piers Cawley" <[EMAIL PROTECTED]>
> "Christian Lemburg" <[EMAIL PROTECTED]> writes:
> > From: "Piers Cawley" <[EMAIL PROTECTED]>
...
> > > 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.
Ah, I see. Yes, we increment the counter each time now.
(Blindness suddenly goes away.)
> > > 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.
OK, why not.
Cheers,
Christian
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/perlunit-devel
