lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Sokolov (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LUCENE-8248) Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy
Date Wed, 11 Apr 2018 20:18:00 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message