TAP::Parser should be *easier* to subclass

[Steve Purkis]

On Jun 3, 2008, at 17:58, Eric Wilhelm wrote:

> # from Steve Purkis
> # on Tuesday 03 June 2008 03:04:
>
>>  I put together a patch for that (follow link above)
>
> Indeed, we had concluded that the constructors needed to not be
> hard-wired.
>
>   +sub _source_class      { 'TAP::Parser::Source' }
>   +sub _perl_source_class { 'TAP::Parser::Source::Perl' }
>   +sub _iterator_class    { 'TAP::Parser::Iterator' }
>   +sub _grammar_class     { 'TAP::Parser::Grammar' }
>
> I think you're headed in the right direction, but these should  
> probably
> not start with '_', and in fact they could just be instance attributes
> (with mutators) so you don't even have to subclass TAP::Parser to
> change this behavior for a given instance.

That shouldn't be a problem.  I went for the above simply because it  
was quicker.  I'll hopefully get some more time to work on this next  
week, at which point I can roll another patch if that'd help.


> This would need to be documented.

Of course...

*steve hides*

;-)


>> 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
>
> I'm not sure where the benefit is here.  Could you please clarify a  
> bit?
> Is it about code reuse or just consistency?  Collecting some of the
> common method definitions into a single spot doesn't have to mean a
> base class.

It's more about consistency than code reuse.  I find being consistent  
gives you one less thing to worry about when coding.  Take the  
_initialize method: because I'd seen it in one place I assumed it was  
used everywhere.  It took me several minutes and the perl debugger to  
realize it wasn't.  Being consistent could have saved me that time  
and (ok, minor) frustration.

Of course it turns out there's already a TAP::Base class, it's just  
not being used everywhere.  Is there any reason for that?


> Unfortunately, compatibility and minimal dependencies dictate that  
> Moose
> and other class composition tools cannot be used.

I figured as much when I saw the accessor generators ;-).

-Steve