[
https://issues.apache.org/jira/browse/LUCENE-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16434509#comment-16434509
]
Mike Sokolov edited comment on LUCENE-8248 at 4/11/18 8:17 PM:
---------------------------------------------------------------
I guess I'm confused why NoMergePolicy must override all inherited methods.
That makes sense for a filter / adapter class -- that is its sole purpose after
all. But NoMergePolicy simply calls the base class method in many cases; why
force it to do so? It doesn't have any risk of shadowing since it is not
supplying its own instance variables
was (Author: sokolov):
I guess I'm confused why NoMergePolicy must override all inherited methods.
That makes sense for a filter / adapter class -- that is its sole purpose after
all.
> Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy
> ------------------------------------------------------------------------------
>
> Key: LUCENE-8248
> URL: https://issues.apache.org/jira/browse/LUCENE-8248
> Project: Lucene - Core
> Issue Type: Wish
> Components: core/index
> Reporter: Mike Sokolov
> Priority: Minor
> Attachments: LUCENE-8248.1.patch, LUCENE-8248.patch, MergePolicy.patch
>
>
> MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is
> not, which means that overriding it with anything other than a trivial
> delegation can only lead to confusion.
> The patch makes the method final and removes the trivial implementations from
> MergePolicyWrapper and NoMergePolicy.
> [~mikemccand] also pointed out that the class name is nonstandard for similar
> adapter classes in Lucene, which are usually Filter*.java. Personally I was
> looking for MergePolicyAdapter, but if there is a prevailing convention here
> around Filter, does it make sense to change this class's name to
> FilterMergePolicy?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
