incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Kurz <>
Subject Re: Class hierarchy
Date Mon, 14 Sep 2009 01:59:01 GMT
On Sat, Sep 12, 2009 at 2:20 PM, Marvin Humphrey <> wrote:
>> > Maybe we should try to have
>> > all second-level namespacing represent grouping only?  In other words, there
>> > would be no instantiable classes with the pattern Lucy::Xxxx -- only
>> > Lucy::Xxxx::Xxxx and deeper.
>> This would make me happier.  And this would make things easier to
>> align with the C scheme, right?
> I'm not sure how it would make things easier... can you elucidate?

I'm definitely out-of-date, and perhaps wrong as well.   I was
thinking that this meant the object code symbol names could be a
mechanical translation of the Perl class name.  Or perhaps this is
best viewed the other way: that the Perl class can simply mirror the
C.  But now I'm not sure:  do you allow for Lucy::Dir1::Class and
Lucy::Dir2::Class, or does 'Class' have to be unique across all
groupings?   What does the Class_func() macro expand to?

Am I right that the C library is primary, and the plan is still to
develop binding to it from multiple languages?  Would the
(hypothetical) Python binding need to be identical to the Perl one?

>> Could we agree that Lucy::Dir::SubClass should subclass
>> Lucy::Dir::Class?  That in general the subclass should add a word in
>> front of the class it derives from?
> Like Huffman, I think that's a nice-to-have.  I'm glad that you've articulated
> the principle, and I agree that we should seek to apply it when possible, but
> it can't be a hard and fast rule.

Agreed that it doesn't need to be hard and fast.

> For example, ORQuery, ANDQuery, NOTQuery and RequiredOptionalQuery all descend
> from PolyQuery -- which is very important, because it allows you to walk a
> hierarchy comprised of disparate PolyQueries.  However, the proposed naming
> scheme implies Lucy::Search::ORPolyQuery, which is no good.

Agreed that this name is not good, but I'm uncertain about the 'very
important' part.   While it might be convenient to define the child
handling functions in a single place, this seems like merely a
convenience. Can the hierarchy be of mixed Queries and PolyQueries?
Could a Query be a special case of a PolyQuery without children (ie,
PolyQuery becomes Query)?

Probably a silly thought


View raw message