[
https://issues.apache.org/jira/browse/LUCENE-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-6021:
---------------------------------
Attachment: LUCENE-6021.patch
Good point Uwe. The reason why I did it this way is that for SparseFixedBitSet
it makes more sense to use #aproximateCardinality() to get a cost. So I
refactored a bit the patch to add an #approximateCardinality() method on BitSet
that forwards to #cardinality() for FixedBitSet and is overridden by
SparseFixedBitSet to use linear counting. Then BitDocIdSet's 2nd constructor
doesn't specialize for FixedBitSet and uses approximateCardinality to get a
cost in all cases. Does it make sense to you?
> Make FixedBitSet and SparseFixedBitSet share a wider common interface
> ---------------------------------------------------------------------
>
> Key: LUCENE-6021
> URL: https://issues.apache.org/jira/browse/LUCENE-6021
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Priority: Minor
> Fix For: 5.0
>
> Attachments: LUCENE-6021.patch, LUCENE-6021.patch
>
>
> Today, the only common interfaces that these two classes share are Bits and
> Accountable. I would like to add a BitSet base class that would be both
> extended by FixedBitSet and SparseFixedBitSet. The idea is to share more code
> between these two impls and make them interchangeable for more use-cases so
> that we could just use one or the other based on the density of the data that
> we are working on.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
