[I'm being very slack in moving things between the qa and london.pm
lists, so far no-one has shouted at me, but apologies in advance]
On Tue, Aug 28, 2001 at 02:31:58PM +0200, Paul Johnson wrote:
> That keeps README up to date with the NAME and DESCRIPTION sections from
> the pod in Cover.pm.
Thanks, to yourself and everyone else, it seems I was being a little
too dense. Will take one of these and mangle it into my Makefile.PLs
some time soon.
> Also, I was wondering if we shouldn't see if there's any common ground
> between Devel::Cover and Pod::Coverage. Maybe in the interface if
> nothing else.
It's certainly worthwhile, the Pod::Coverage interface is growing a
little haphazardly as all the little lights go on in my head. Next up
will be the moral opposite to the $obj->naked method, so you can see
what is successfully being covered up. Comedy names welcome,
currently shortlisted are C<sheathed> and C<modest>
Also I need to do something about classes intended for tying - which
raises a more general question. How consistent is the convention held
that UPPERCASE subroutines are special to [Pp]erl, and so likely to be
private, or at least have implicit documentation from elsewhere[0].
I'd also like to use some of your shinyness to identify comments
preceding private methods though maybe it's a more worthwhile to
encourage a convention such as qq{=for internals\n\n=item private}[1]
so modules with good internal documentation can get karma for that as
well as covering their external interfaces.
Doing that could also mean that the module would be more naturally
named as Devel::Cover::Docs, so Devel::Cover can be more of a one-stop
code audit shop. I'd be keen to make Pod::Coverage still be usable on
it's own though, since without the deep magic that could use the
pluggable runops I hope to make a stab at backporting to 5.004_04[2]
I'm still chewing over the issues Tony raised, but a quick refactor to
make subclassing easier is certainly on the cards. Planned though is
to make little additions to the existing interface to make the common
cases more of a configuration issue than needing to plug in too much
code. Doing a check-in test against perceived coverage does sound
cool though.
</brain dump>
[0] Since this may heal itself when you examine the pods of parent
classes.
[1] Note to self, subscribe to the podpeople list - I can't get at
http://lists.perl.org/ from where I am right now, could someone
forward me on subscription info.
[2] I have MacPerl ready to go for when the tuits present themselves,
but I suspect it may be as simple as just dropping the use of
qr//, or as difficult as sacrificing something to the arcane ones
of Devel::*
--
Richard Clamp <[EMAIL PROTECTED]>
happy people have no stories
