[KinoSearch] Re: Subclassable Highlighter

[Marvin Humphrey]

On Feb 29, 2008, at 11:29 AM, Father Chrysostomos wrote:

>> How about if we change highlight() to use variables which are  
>> settable via accessors?
>>
>> __PACKAGE__->ready_get_set(qw( pre_tag post_tag ));
>>
>> sub highlight { "$pre_tag{$$self}$_[1]$post_tag{$$self}" }
>
> This sounds fine. I’m working on a patch.

:)

>> I'd really like to kill off those four classes.
>
> Does it have to be all four? We could keep Encoder, and have  
> Highlighter accept a code ref, as well as an Encoder object. If  
> Highlighter is ever ported to C, then XS code could wrap a code ref  
> in an Encoder subclass.

If Highlighter gets ported to C, it will remain the default to call  
back to Perl for encode().  You'll still be able to override it with a  
basic subclass.

   package MyHighlighter;
   use base qw( KinoSearch::Highlight::Highlighter );

   sub encode { ... }

   1;

If you want to keep around a special object to handle encoding duties,  
you can do that too, via an inside-out var:

   package UberHighlighter;
   use base qw( KinoSearch::Highlight::Highlighter );

   my %encoder;

   sub new {
      my $class = shift;
      my $self  = $either->SUPER::new(@_);
      $encoder{ refaddr $self } = UberEncoder->new;
      return $self;
   }

   sub encode {
       my ( $self, $text ) = @_;
       return $encoder{ refaddr $self }->encode($text);
   }

   sub DESTROY {
       my $self = shift;
       delete $encoder{ refaddr $self };
       $self->SUPER::DESTROY;
   }

In either case, it's really no more work than providing your own  
custom subclass of the present version of Encoder.  It would be a  
slightly different story if SimpleHTMLEncoder took params, because  
then you might be spared from having to subclass in some cases.  But  
since all SimpleHTMLEncoder does is override encode(), there's no  
advantage.

Marvin Humphrey
Rectangular Research
http://www.rectangular.com/