commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedikt Ritter (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TEXT-16) Improve HumanNameParser
Date Sun, 03 May 2015 09:49:06 GMT

    [ https://issues.apache.org/jira/browse/TEXT-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14525749#comment-14525749
] 

Benedikt Ritter commented on TEXT-16:
-------------------------------------

Sorry for the confusion! I meant there should be an API for deriving ParserOptions from one
another. Like:

{code:java}
ParserOptions myOptions = ParserOptions.DEFAULT_OPTIONS.addSuffix("del Roca");
{code}

Which would create a new instance that is a copy of the DEFAULT_OPTIONS but with an additional
suffix.

While writing this down, I'm wondering if we're making thinks to complicated here... maybe
we should aim for a non configurable parser at the start and implement configuration options
when users request them?

> Improve HumanNameParser
> -----------------------
>
>                 Key: TEXT-16
>                 URL: https://issues.apache.org/jira/browse/TEXT-16
>             Project: Commons Text
>          Issue Type: Improvement
>            Reporter: Bruno P. Kinoshita
>            Assignee: Benedikt Ritter
>            Priority: Minor
>              Labels: Refactoring
>
> From http://markmail.org/thread/da7ayocit2dl4otv
> - The constructor of the parser takes configuration options which can be
> reused for several names to parse
> - the parse method takes a string as parameter, containing a name
> - the parse method returns an immutable Name objects which has getters for
> firstName, lastName etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message