incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Kurz <>
Subject Re: [lucy-dev] Three class name changes
Date Sat, 02 Apr 2011 19:39:10 GMT
On Sat, Apr 2, 2011 at 11:03 AM, Marvin Humphrey <> wrote:
> On Sat, Apr 02, 2011 at 07:25:45AM -0500, Peter Karman wrote:
> > The name change to Investigation is not meant to prejudice the decision to zap
> > or not to zap,
>> Investigation seems a little awkward as a name.
> True.

I'm almost in favor of Investigation because it's so clunky that we
are sure to get rid of the class just so we can stop looking at the
name. :)

>>  "The purpose of the Compiler class is to take a specification in the form of a
>> Query object and compile a Matcher object that can do real work."
> Yes, that's the role of Compiler that we currently emphasize.  It's possible
> to see it from other perspectives, though.

We agree that the name should match the purpose, although I prefer
simplifying the class rather than complexifying the name.

> Now, when I
> say "It's the Compiler's job to create raw highlighting data", that sounds
> strange.  If you're not familiar with the Compiler class, you're going to
> think I meant the C compiler -- and what on earth could the C compiler have to
> do with highlighting?

This confusion isn't because one assumes "C Compiler", but rather why
any Compiler would do this.  Why does it create raw highlighting data
again?   But I feel like I'm being too curmudgeonly and not
sufficiently constructive.


I think it would help tremendously to refine the high level overview
of how the classes interact.  Once we are able to discuss that
succinctly, I think we'll have a much easier time naming the
individual classes.    I think it may turn out that some parts
(QueryParser[*], Compiler/Investigator) are merely procedural details
organized into classes, rather than real public facing objects (Query,
Matcher).   If we have a clear narrative first, and match the names to
that necessarily simplified story, we stand a much better chance of
finishing with something coherent and accessible.

Marvin --- can you write up a single page overview of this?  If we can
get that story solid, the rest will follow a lot easier.


[*] I think QueryParser illustrates my perspective.  It doesn't really
matter to me whether there is a QueryParser object, only that there is
a means a transform a string into a Query.  Equally, I don't think
there really should be any emphasis on a [Query]Compiler, so long as
there is some means to transform a abstract Query into an index
specific Matcher.  The narrative I want would thus be quite specific
about what a Query object is and contains (that it is not tied to a
document collection), but probably wouldn't even need to mention the
specific QueryParser class.  Do we really need an Investigator object
per se, or just a class that contains some functions for creating a

View raw message