[KinoSearch] Subclassable Highlighter

[Marvin Humphrey]

On Feb 2, 2008, at 11:40 AM, Father Chrysostomos wrote:

> Is there any reason why a custom encoder should have to inherit from  
> KS:H:E?

KinoSearch executes method dispatch at two levels.  There's the Perl  
level, which you are familiar with.

The second dispatch mechanism uses virtual tables at the C level.   
This mechanism is *much* faster, but it is less flexible.  Only single  
inheritance is supported.  Method names must be resolved at compile  
time, because the function pointer associated with a method name  
exists at a fixed offset in the vtable for every descendent of the  
parent class where the method is first defined, and compiled method- 
invocation code knows only the offset.

If you cannot translate the method name to an offset at compile time,  
you have to use a runtime hash lookup of the method name, which the KS  
vtable mechanism does not support (except via "native" callbacks to  
Perl).  If we allow arbitrary, duck-typed objects here, it would be  
the only spot in all of KS to deviate from single-inheritance, and the  
only spot that absolutely could not be ported to C.

As a matter of principle, I'd like to keep the entirety of the KS  
interface within the least-common-denominator single-inheritance OO  
model.  That gives us maximum flexibility to move implementations back  
and forth between the C layer and the host language layer, and  
potentially makes it easier to offer consistent APIs across multiple  
bindings.

> And, considering that there is only one method, can we not also  
> allow a code ref?

How about this instead?

   * Eliminate Encoder, Formatter, SimpleHTMLEncoder, and
     SimpleHTMLFormatter.
   * Add public encode() and highlight() methods to Highlighter.

   sub encode    { return encode_entities( $_[1] ) }
   sub highlight { return '<strong>' . $_[1] . '</strong>' }

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