On Sat, Sep 12, 2009 at 2:20 PM, Marvin Humphrey <[email protected]> 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 --nate
