[
https://issues.apache.org/jira/browse/LUCENE-7208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15238887#comment-15238887
]
Robert Muir commented on LUCENE-7208:
-------------------------------------
{quote}
They in fact are decoupled in Anders's original implementation.
{quote}
I know, and this is better.
{quote}
There's an argument to be said for that – I understand. I have no compelling
reason to say it should stay coupled. I happen to be using it in some code that
has multiple CharRunAutomaton instances, and it would like to merge/union them
as an optimization instead of looping over them for matching a char[]. The
simplest thing is to expose the automaton, then union them, then build a new
CharRunAutomaton. Another option would be to somehow actually merge the
compiled/determinized automata, although the state isn't exposed to do that.
Any way, it's not a big deal.
{quote}
I don't see it that way. Instead i see no argument for this getter, other than
your code is buggy and you should have multiple Automaton in *your* api instead
of these.
> Expose Automaton getter on RunAutomaton
> ---------------------------------------
>
> Key: LUCENE-7208
> URL: https://issues.apache.org/jira/browse/LUCENE-7208
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/FSTs
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Minor
> Attachments: LUCENE_7208.patch
>
>
> RunAutomaton is (of course) built from an Automaton and it stores it on a
> field, package-private. It would be convenient to expose it via a getter.
> In fact CompiledAutomaton wants it.
> While we're at it, lets mark all the fields private and ensure that the only
> classes using its state (currently its 2 subclasses) use the getters that
> already exist for what they need. Those getters are already final so I don't
> expect a performance impact.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
