[
https://issues.apache.org/jira/browse/LUCENE-7208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237449#comment-15237449
]
David Smiley commented on LUCENE-7208:
--------------------------------------
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.
> 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]
