<br><font size=2 face="sans-serif">Hi all,</font>
<br>
<br><font size=2 face="sans-serif">I just wanted to bring this to your
attention, and maybe start a discussion on this:</font>
<br>
<br><font size=2 face="sans-serif">http://rt.cpan.org/Ticket/Display.html?id=36397</font>
<br>
<br><font size=2 face="sans-serif">Summary:</font>
<br><font size=3>I've been trying to sub-class TAP::Parser to replace the
TAP::Parser::Source::Perl module with a custom one, and am finding I'd
have to re-implement a *lot* of code to do it. &nbsp;I came to the conclusion
that it would be easier to patch TAP::Parser to make this behaviour *easily*
achievable than have to maintain a custom version of TAP::Parser. &nbsp;I
put together a patch for that (follow link above)</font>
<br>
<br><font size=3>To make it even easier to subclass, I would recommend
introducing a common base class for *all* TAP:: modules in the distro,
eg: TAP::Base. The reason? Because there are currently a hundred different
customized 'new' methods</font>
<br>
<br><font size=3>Why would this help? Because I came across an _initialize
method, and assumed it was being used everywhere. I was surprised (and
annoyed) when I found out it wasn't. It's not consistent, which makes subclassing
more painful that it should be.</font>
<br>
<br><font size=2 face="sans-serif">I've only had time to put together a
patch that covers the functionality I need to override. &nbsp;I think more
time will need to be spent on this to give TAP::* a more consistent, easy-to-subclass
feel across the board.</font>
<br>
<br><font size=2 face="sans-serif">Thoughts?</font>
<br>
<br><font size=2 face="sans-serif">-Steve</font>
<br>
<span style="font-family:sans-serif,helvetica; font-size:10pt; color:#000000">---<br>
<br>
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.<br>
<br>
Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.</span><br>