On Tue, Dec 19, 2006 at 04:17:07PM -0800, chromatic wrote:

> On Tuesday 19 December 2006 16:04, Joshua ben Jore wrote:
> 
> > It'd be nice if there were a pragma or function for use by
> > Devel::Cover which said just that:

 cond ? ... :
 cond ? ... :
 cond ? ... :
 can't::happen;

 sub can't::happen { Carp::confess q[This can't happen] }

That would be the "uncoverable" feature, which I haven't quite finished
yet.  It does just what is asked for, that is you can mark constructs as
uncoverable which means that the sense of the error is reversed - the
construct will be in error iff it is executed.

There are three main sections of work still left to be completed:

 1.  Find some nice way expressing what is uncoverable.  For subroutines
     this is easy.  For statements it is not hard.  For branches it is
     tricky and for conditions I'm somewhat stumped.  The current
     method I use is based on implementation details.

 2.  Make all the reports honour this feature.  The text and html_basic
     reports do so, but the (default) html report doesn't.

 3.  Provide a way to specify uncoverable code within the source file.
     I'm surprised that many people want this, but they do.

The basics of this functionality have been there for a while, but I've
not found any time to work on things recently.  Until the API is
complete it is deliberately not documented.  Anyone wanting to play for
it can grep the source for "uncoverable" and use the feature.  It
actually works quite well, apart from the limitations above.

> Nicer yet would be if Devel::Cover (and I haven't tried in a few months; too 
> busy with other things, so if there's a fix now, not only will I learn about 
> it by shooting off my mouth, but you'll all learn about it too) would 
> consider constants on the right side of || as, well, constant.

This should already be the case, and I don't think there have been many
changes there in the last few months.  I'm fairly sure of this since
there haven't been any releases in the last few months ;-)

So if you (or anyone else) has any examples where this is not doing the
right thing please send them to me, either as code snippets or as
patches to tests/cond_or.

> I'm not sure what kind of hack it would take to make the empty string 
> unconstant, but I promise I'm not using it in my code right now.

Such ideas are the bane of my life as Devel::Cover's author.  But I
think that anyone who makes undef return 42 randomly probably deserves
whatever they get.  Yes, Juerd, I'm scowling at you.

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

Reply via email to