Re: [Perlunit-devel] new filtering mechanism, and documentation issues

[Matthias F. <mf...@hi...>]

I'm a big fan of more documentation vs. less documentation.  The old
standby, "This function is subject to change in the future, use at your
own risk," can be a big help in this situation, and will help to
distinguish the stable parts from the unstable parts.  Yes?

On Thu, 20 Jun 2002, Adam Spiers wrote:

> I just committed a nice filtering enhancement.  From the ChangeLog:
> 
>   - remove ALL filtering hack, and instead allow filtering via coderefs:
> 
>       sub filter {{
>           foo_tests  => sub {
>               my $method = shift;
>               return $method =~ /foo/;
>           },
>           everything => sub { 1 },
> 
>           # method lists still work
>           another_token => [ qw/test_method1 test_method2/ ],
>       }}
> 
> Documentation is slowly improving on the more esoteric stuff too.
> Up till now the classes used internally by the framework have not been
> documented, the idea being that only PerlUnit developers should need
> to understand them.  However it seems to me that it's a far old grey
> area between where the framework stops and where the developer takes
> over, so I've been thinking that maybe the framework should appear
> more open, by being fully documented.  Any opinions?
> 
> 
> -------------------------------------------------------
>                    Bringing you mounds of caffeinated joy
>                    >>>     http://thinkgeek.com/sf    <<<
> 
> _______________________________________________
> Perlunit-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perlunit-devel
>