[
https://issues.apache.org/jira/browse/LUCENE-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer updated LUCENE-2183:
------------------------------------
Attachment: LUCENE-2183.patch
Here is a first proposal of a slightly new API that rather decouples the
"isTokenChar" predicate and the "normalize" method instead of enforceing
CharTokenizer subclasses and overriding methods.
I introduced a new class TokenCharFunctions that is passed to the constructor
of CharTokenizer and is used internally. The patch preserves full backwards
compat and provides a clean way to move towards a consistent codepoint based
API with would still provide the flexibility to make use of the old and buggy
behavior even if the char based methods are removed.
I consider this patch as a basis for the discussion how to solve this problem.
other approaches would be using reflection like the TokenStream BWCompat layer
does but I personally prefer not to use reflection and rather use delegation in
favor of inheritance.
looking forward to see some comments.
> Supplementary Character Handling in CharTokenizer
> -------------------------------------------------
>
> Key: LUCENE-2183
> URL: https://issues.apache.org/jira/browse/LUCENE-2183
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Analysis
> Reporter: Simon Willnauer
> Fix For: 3.1
>
> Attachments: LUCENE-2183.patch
>
>
> CharTokenizer is an abstract base class for all Tokenizers operating on a
> character level. Yet, those tokenizers still use char primitives instead of
> int codepoints. CharTokenizer should operate on codepoints and preserve bw
> compatibility.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
