incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: Stable releases under new namespaces
Date Mon, 15 Mar 2010 00:21:54 GMT
On Sun, Mar 14, 2010 at 02:30:48PM -0500, Peter Karman wrote:
> I like this approach. It's more work for KS developers, in terms of managing
> api versions, but that's good work to do, since it requires making the api
> changes very explicit.

I understand that this sounds attractive in theory, but it's not practical.
Certainly having two versions run side by side won't ever work.  We can't
search-and-replace within compiled XS objects to substitute "KinoSearch" for
"KinoSearch3".  Does Query_Is_A(query, ORQUERY) pass, fail, or segfault
when "query" was created under KinoSearch3, but ORQUERY is a VTable owned by
KinoSearch4, aliased to KinoSearch?  What should factory methods spit out, and
how will they know?  How will type checking across the Perl/C border work?

Changing up behaviors using an api_version key can work within a single
object, using one of the following strategies:
   * Store api_version as a member variable and switch up behavior based on
     its value.  That's what HTML::Parser does, I believe.
   * Have the constructor dispatch based on api_version and return objects
     blessed into different classes.
   * Store an API-specific object within the main object and dispatch to that.

However, KinoSearch is a highly performance-sensitive library with hundreds of
classes and lots of interaction between all the various parts.  Furthermore,
it doesn't use hash-based method dispatch, but compile time binding -- which
is much faster, but also means that invoking an invalid method on an object
results in a memory error rather than a catchable exception.  At best that's a
segfault, at worst it's a security hole.

Marvin Humphrey

View raw message