On Sun, Sep 13, 2009 at 06:59:01PM -0700, Nathan Kurz wrote:
> do you allow for Lucy::Dir1::Class and Lucy::Dir2::Class, or does 'Class'
> have to be unique across all groupings?
'Class' has to be unique across all groupings.
At least within the confines of Lucy. Theoretically you could create another
Boilerplater "parcel" -- e.g. "Lucy2", or "KinoSearch", or "LucyX" -- which
also had a "Class". That's not well developed in Boilerplater because it
hasn't been been necessary yet, but it's doable.
>From the Boilerplater overview documentation:
Within a parcel, the last part of each class name must be unique.
class Crustacean::Lobster::Claw { ... }
class Crustacean::Crab::Claw { ... } /* Illegal, "Claw" already used */
> What does the Class_func() macro expand to?
Assuming that the parcel is "Lucy", lucy_Class_func().
> Am I right that the C library is primary, and the plan is still to
> develop binding to it from multiple languages?
Yes, absolutely.
> Would the (hypothetical) Python binding need to be identical to the Perl one?
I'm not sure what you mean by "identical", but maybe this comment is germane:
https://issues.apache.org/jira/browse/LUCY-5?focusedCommentId=12681836&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12681836
Actually, I don't think we're going to be able to use the same shared object
with multiple bindings. Python will need its own, C will need its own, Perl
will need its own, etc – and therefore, there will never be a normal case
where the bindings and the core library are out of sync.
The reason the core cannot be shared is that each binding has to implement
some functions which are declared by the core but left unimplemented – for
example, the functions which implement callbacks to the host. The object
code
from those implementations will end up in the shared object.
> Can the hierarchy be of mixed Queries and PolyQueries?
Sure, that's the normal case -- but you can't walk children of ordinary Query
objects, because Query doesn't have a "Get_Children" method. So effectively,
anything that's not a PolyQuery is a leaf node.
> Could a Query be a special case of a PolyQuery without children (ie,
> PolyQuery becomes Query)?
If we were to give Query an abstract Get_Children() method, we might be able
to eliminate PolyQuery. But that doesn't seem like the best solution to me,
because having child nodes isn't fundamental to a Query.
Marvin Humphrey
