Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Devel-Cover CPAN distribution.

Report information
The Basics
Id: 16222
Status: open
Priority: 0/
Queue: Devel-Cover

People
Owner: Nobody in particular
Requestors: sargie [...] cpan.org
tylerm [...] activestate.com
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Subject: Regular expressions have conditions too!
X-RT-Original-Encoding: iso-8859-1
Content-Length: 907
Download (untitled) / with headers
text/plain 907b
Hello, I've been using Devel::Cover for a few months now and I love it. It's made it *way* easier to write clean, bug-free code and unit tests. One thing that just occured to me while writing a validator as a regular expression, is that regexp's have conditions too. I don't know how easy it would be to get this functionality in, but given a regular expression like: qr/something|someotherthing/ I think it would be helpful to have coverage analysis showing you which parts of the regular expression got matched. With more complicated regular expressions, like qr/(1|2|(456|654))|((?:(1|2)|(3|4))456(7|8))/ I could see the specification for what was matched and what wasn't getting really long (and it probably wouldn't be appropriate to use the same "A B C D" notation as standard code conditions). What do you think? Is this feasable? Insane? Thanks, Tyler
MIME-Version: 1.0
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Disposition: inline
Message-Id: <rt-3.6.HEAD-16734-1154517055-1354.16222-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Original-Encoding: utf-8
Content-Length: 186
Download (untitled) / with headers
text/plain 186b
Yes, this is true. Regular expressions are their own little language and could be covered too. But this is not something I'm planning on doing right now. It's on the TODO list though.
Subject: Substitutions with /e
MIME-Version: 1.0
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Type: text/plain; charset="utf8"
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 188
Download (untitled) / with headers
text/plain 188b
Either the Tutorial is wrong in saying: "100% branch coverage implies 100% statement coverage." OR s/foo/bar()/e; should flag as a branch not followed if bar() is not executed... +Pete
X-Source:
MIME-Version: 1.0
X-Spam-Status: No, hits=-2.5 required=8.0 tests=BAYES_00,FORGED_RCVD_HELO
In-Reply-To: <rt-3.6.HEAD-28211-1160403452-1164.21975-4-0 [...] rt.cpan.org>
X-Source-Args:
Content-Disposition: inline
X-Source-Dir:
Received-SPF: neutral (x1.develooper.com: local policy)
References: <RT-Ticket-21975 [...] rt.cpan.org> <rt-3.6.HEAD-28211-1160403452-1164.21975-4-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
X-Antiabuse: This header was added to track abuse, please include it with any abuse report
X-Antiabuse: Primary Hostname - tiger.phpweb.biz
X-Antiabuse: Original Domain - rt.cpan.org
X-Antiabuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-Antiabuse: Sender Address Domain - pjcj.net
X-RT-Original-Encoding: us-ascii
Received: from la.mx.develooper.com (x1.develooper.com [63.251.223.170]) by diesel.bestpractical.com (Postfix) with SMTP id 878E74D80D9 for <bug-Devel-Cover [...] rt.cpan.org>; Fri, 29 Dec 2006 19:03:01 -0500 (EST)
Received: (qmail 13652 invoked by alias); 30 Dec 2006 00:03:00 -0000
Received: from tiger.phpweb.biz (HELO tiger.phpweb.biz) (64.246.62.13) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Fri, 29 Dec 2006 16:02:58 -0800
Received: from 84-73-176-38.dclient.hispeed.ch ([84.73.176.38] helo=wesley.pjcj.net) by tiger.phpweb.biz with esmtpa (Exim 4.63) (envelope-from <paul [...] pjcj.net>) id 1H0Rg3-00074P-Qs for bug-Devel-Cover [...] rt.cpan.org; Fri, 29 Dec 2006 18:02:20 -0600
Received: from pjcj by wesley.pjcj.net with local (Exim 3.36 #1 (Debian)) id 1H0RgZ-0003RP-00 for <bug-Devel-Cover [...] rt.cpan.org>; Sat, 30 Dec 2006 01:02:51 +0100
Delivered-To: cpan-bug+devel-cover [...] diesel.bestpractical.com
Subject: Re: [rt.cpan.org #21975] Substitutions with /e
User-Agent: Mutt/1.5.13 (2006-08-11)
Return-Path: <paul [...] pjcj.net>
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: bug-Devel-Cover [...] rt.cpan.org
Date: Sat, 30 Dec 2006 01:02:51 +0100
Sender: Paul Johnson <paul [...] pjcj.net>
Message-Id: <20061230000251.GN2517 [...] pjcj.net>
To: via RT <bug-Devel-Cover [...] rt.cpan.org>
From: Paul Johnson <paul [...] pjcj.net>
X-RT-Original-Encoding: utf-8
RT-Message-ID: <rt-3.6.HEAD-1919-1167436986-120.21975-0-0 [...] rt.cpan.org>
Content-Length: 630
Download (untitled) / with headers
text/plain 630b
On Mon, Oct 09, 2006 at 10:17:33AM -0400, via RT wrote: Show quoted text
> Either the Tutorial is wrong in saying: > > "100% branch coverage implies 100% statement coverage." > > OR > > s/foo/bar()/e; should flag as a branch not followed if bar() is not > executed...
I think I agree with this in principle, but it's really not something I want to deal with at the moment. The TODO list mumbles something about Regular Expression coverage, and should that ever become a reality, this case should fall out from that. So I'm going to leave this as stalled until that happy day. Thanks, -- Paul Johnson - paul@pjcj.net http://www.pjcj.net
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-18075-1334321186-1176.16222-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
RT-Send-CC: paul [...] pjcj.net
Content-Length: 436
Download (untitled) / with headers
text/plain 436b
Le 2005-11-30 22:52:30, CRAKRJACK a écrit : Show quoted text
> One thing that just occured to me while writing a validator as a > regular expression, is that regexp's have conditions too. I don't > know how easy it would be to get this functionality in, but given a > regular expression like: > > qr/something|someotherthing/
The module re::engine::Hooks may help for this task... -- Olivier Mengué - http://perlresume.org/DOLMEN


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.