Resurrecting a very old topic. It turns out I managed to do this to create a "new" analyzer it it has been working flawlessly. Recently I saw the need to add attributes to my analyzer (more specifically, I need to pass a language to it).
My first attempt was to use the same method to subclass EasyAnalyzer instead of Analyzer (basically replacing ANALYZER by EASYANALYZER and adapting everything else as needed) to use the fact that EasyAnalyzer already has a language field, but this did not work (i.e. my overridden transform method was never called and the EasyAnalyzer one was being called instead). So, my question is: Using the trick of overriding specific methods form Analyzer during runtime, is there a way I can also create my own ivars and attach it to my overriden analyzer? While we are at this, this is all Lucy 0.4.2 (yeah, I know, old) and I am considering moving to the latest version mostly due to the now included golang bindings. I didn't look a lot at the golang bindings yet but will it be possible to create a new analyzer in a non-hackish way and entirely in go using it? Thanks in advance. On Tue, Mar 31, 2015 at 10:54 AM Marvin Humphrey <[email protected]> wrote: > On Tue, Mar 31, 2015 at 10:28 AM, Bruno Albuquerque <[email protected]> > wrote: > > Sure, and it matches with my original understanding about what should be > > done. I got doubts when I saw the modules directory with snowball in it. > > > > Lucene appears to support a lot more languages out of the box. Are there > > plans for Lucy to support other languages? (even if Lucy has no formal > > notion of language support, this is an important part of IR). > > Lucene is a gigantic project with an army of developers working on it. > It's > not realistic to shoot for feature parity, and if we tried, we would be so > busy porting cruft that we couldn't achieve the two priorities that matter > most > to present members of the Lucy development community: adding support for > more > programming languages to our symbiotic object system "Clownfish", and > refactoring Lucy's matching framework to facilitate certain assembler-level > optimization techniques. > > If new members of the Lucy community were to contribute support for > additional > languages, though, we'd presumably find ways to acommodate them. > > Marvin Humphrey >
