lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [lucy-dev] Host QueryParser reimplementations
Date Sat, 30 Apr 2011 18:06:18 GMT
On Sat, Apr 30, 2011 at 11:24:53AM -0500, Peter Karman wrote:
> Namespaces: LucyX follows the Perl convention of the appended 'X' for
> eXtensions. I like that the name immediately distinguishes it from the core lib
> distribution. 

Exactly.  It's in the tradition of DBIx, MooseX, CatalystX, and so on.

Short of truly eggregious trademark violation that the ASF is legally
compelled to go after, extension developers have the option of identifying
their products using "Lucy" rather than "LucyX".  As a user, though, I prefer
it when extensions are clearly identifiable as such, and I believe that as
library developers we should encourage use of the LucyX namespace.

> But I also like the idea of host-language distinction.
> LucyX::Perl, LucyX::Python, etc.  ?

I'm not opposed, but I have some misgivings.  Most users will use Lucy within
the context of a single host language, and extensions built in other languages
will not be visible under ordinary circumstances.  Presumably you would not
find LucyX.Perl.QueryParser while searching PyPI, or
LucyX::Python::QueryParser while searching CPAN -- so the "Perl" and "Python"
components within those names do not convey much useful information.

How about simply LucyX::Search::QueryParser for the name of this distribution?
The distinguishing characteristic of the proposed project is that it is a
faithful reimplementation of the Lucy::Search::QueryParser.  There aren't
supposed to be any behavioral differences -- so in this case, it's arguably
appropriate to distinguish only on Lucy/LucyX.

Then, for the actual classes, perhaps we should name them based on the parser
generator they use.

    LucyX::Search::QueryParser::PRD       <---- Parse::RecDescent (Perl)
    LucyX.Search.QueryParser.PyParsing    <---- PyParsing (Python)
    LucyX.Search.QueryParser.PLY          <---- PLY (Python)
    LucyX::Search::QueryParser::TreeTop   <---- TreeTop (Ruby)

Since there's no expectation that these classes will ever have C
implementations, we're not bound by Clownfish's naming constraint that the
last element of the class name identify the class completely, and we can use
the naming convention that people seemed to prefer from the user list
discussion a few weeks ago.

Marvin Humphrey

View raw message