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
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/perlunit-devel
>
-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/perlunit-devel
