"Christian Lemburg" <[EMAIL PROTECTED]> writes:
> From: "Piers Cawley" <[EMAIL PROTECTED]>
>
> > As an aside. I have a dream. I have a dream that one day we'll've
> > eliminated inner classes from Test::Unit. Or at least made them take
> > hashes of coderefs instead of strings...
>
> Well, if you feel like it, go ahead. The main use of this inner classes
> stuff was easier porting. Try and port java code to perl without this
> feature. You will go nuts in no time. These java folks use inner classes
> all the time. It was so much easier just to emulate the feature.
> (Besides, who would want to tolerate the fact that Java can do
> something that Perl can't emulate.)
It's not so much the Test::Unit::InnerClass that I don't like as the
way in which it's implemented using a string instead of coderefs.
For instance, what would happen if I were to pass
Test::Unit::InnerClass::make_inner_class something like:
T::U::IC->make_inner_class(BaseClass, <<'EOC');
$inner_class_name = "SomethingWeird";
$i = 9999;
EOC
Okay, so it's unlikely to happen, but there is a danger of spooky
action at a distance simply because the code string gets evalled in a
strange context.
Better to do:
T::U::IC->make_inner_class(BaseClass,
{method1 => sub {...},
method2 => sub {...},
...}, @args);
That way the closures get created in a predictable place, and syntax
errors can be caught at compile time. However, last time I tried doing
this, it proved not to be a straightforward drop in replacement. Time
to take another look methinks.
> But now, since we're done porting, we probably should care more
> about doing things "the perlish way", if just to raise acceptance
> levels.
>
> (As an aside: I'm still confused what "the perlish way" means -
> I always thought there was this TIMTOWTDI thing).
There is that.
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/perlunit-devel
