lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Wellnhofer <>
Subject Re: [lucy-dev] Promoting new analysis components
Date Wed, 08 Feb 2012 16:04:56 GMT
On 23/12/2011 04:18, Marvin Humphrey wrote:
> Now that EasyAnalyzer is in, I think we should promote the use of all the
> improvements Nick has made to the analysis chain.
>    * Swap in EasyAnalyzer for PolyAnalyzer, Normalizer for CaseFolder, and
>      StandardTokenizer for RegexTokenizer everywhere we can.


>    * Deprecate the "language" parameter to PolyAnalyzer#new.
> By "deprecate", I mean:
>    * Open a JIRA issue so that a suitably titled entry ends up in the CHANGES
>      file.
>    * Mark the "language" param as "deprecated" in the PolyAnalyzer docs.
> We don't have a strong deprecation mechanism available to us right now, so I
> think that's the best we can do.

I just noticed that I removed the "language" parameter from the 
PolyAnalyzer docs, but I can revert that part of my commit and mark it 
as deprecated.

Regarding the JIRA issue: I couldn't find a good issue type for 
deprecations. "Task" seems the most appropriate to me.

> It's not important that any of these changes happen before 0.3.0.  The docs
> changes can happen at any time, and the parameter deprecation only allows the
> simplification of a single class (PolyAnalyzer itself).  It would also be nice
> to switch most test cases to use the new Analyzers, but that can also happen
> at any time.

The tests have been converted, too.

> In contrast, here are a couple changes we should *not* make prior to 0.3.0,
> because they have index compatibility implications:
>    * Change Lucy::Simple to use EasyAnalyzer instead of PolyAnalyzer.

I've done that now.

>    * Implement CaseFolder as a subclass of Normalizer.

This has yet to be done. We could also mark the CaseFolder as deprecated 
and remove it completely later.


View raw message