[Xapian-tickets] [Xapian] #448: Allow usage of custom stemmers
Xapian
nobody at xapian.org
Sun Feb 14 23:57:08 GMT 2010
#448: Allow usage of custom stemmers
-------------------------+--------------------------------------------------
Reporter: esizikov | Owner: olly
Type: enhancement | Status: reopened
Priority: normal | Milestone:
Component: Library API | Version: 1.0.17
Severity: normal | Resolution:
Keywords: | Blockedby:
Platform: All | Blocking:
-------------------------+--------------------------------------------------
Changes (by olly):
* status: closed => reopened
* resolution: duplicate =>
* version: => 1.0.17
* component: Other => Library API
Comment:
OK, your initial description and the contents of the first two patches
strongly suggested you were just trying to subclass Xapian::Stem in
Python, which really won't work. I don't think you need to enable
directors for Xapian::Stem with your actual approach, and I also don't see
why need to make Xapian::Stem's destructor virtual (since Xapian::Stem has
no other virtual methods, and the destructor of your subclass doesn't do
anything, I can't see why you need to do this).
We can't make a change in 1.0.x which involves changing the library ABI
incompatibly, and making Xapian::Stem's destructor virtual would be such a
change, so if you do need to do that, this would have to be a trunk-only
change.
But if these alternative stemmers are useful, then I think it is better to
build them in at the C++ API level - it's really an implementation detail
whether they are part of Snowball or not, and that way they will
automatically work from C++ and any wrapped language.
Casting away const to write into the result of calling std::string::data()
is undefined behaviour, so don't do that!
Also, your claim of sole copyright on xapian_hunspell_stemmer.cpp is
rather dubious since the definition of create_s() is lifted verbatim from
Xapian's steminternal.cc (although it seems create_s() isn't actually used
in your code). We need to be particularly careful about tracking the
copyright status of files in Xapian as we want to reach a point where we
can relicense the code, but there are currently copyright holders who
aren't interested in doing so.
--
Ticket URL: <http://trac.xapian.org/ticket/448#comment:4>
Xapian <http://xapian.org/>
Xapian
More information about the Xapian-tickets
mailing list