[ 
https://issues.apache.org/jira/browse/LUCENE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558997#action_12558997
 ] 

Eks Dev commented on LUCENE-584:
--------------------------------

Michal, would this work? 
1. providing default implementation for basic methods that is using skipping 
iterator(always there), so it works by default for *all* implementations, 
something along the lines:

/**
 * A DocIdSet contains a set of doc ids. Implementing classes must provide
 * a [EMAIL PROTECTED] DocIdSetIterator} to access the set. 
 */
public abstract class DocIdSet {
        public abstract DocIdSetIterator iterator();

public  DocIdSet and(DocIdSet){
// default implementation using *iterator*;
}

public  DocIdSet or(DocIdSet){
// default implementation using iterator;
}

}

2.  And then we *optimize* particular cases, e.g

public class DocIdBitSet extends DocIdSet{   
        BitSet bits; // Must be there in order for iterator to work....

        public DocIdSetIterator iterator(){
                //this is easy...
        }

public  DocIdSet and(DocIdSet dis){
        if (dois instanceof DocIdBitSet) {
                //not exactly like this, but the idea is there
                 this.bits.and(((DocIdBitSet) dis));
                 return this;
        }
        return super.and(DocIdSet);
  
 }
}

So it works always, and it works fast if need be, one instanceof check does not 
hurt there. Did I miss something obvious?





> Decouple Filter from BitSet
> ---------------------------
>
>                 Key: LUCENE-584
>                 URL: https://issues.apache.org/jira/browse/LUCENE-584
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>    Affects Versions: 2.0.1
>            Reporter: Peter Schäfer
>            Assignee: Michael Busch
>            Priority: Minor
>             Fix For: 2.4
>
>         Attachments: bench-diff.txt, bench-diff.txt, 
> ContribQueries20080111.patch, lucene-584-take2.patch, 
> lucene-584-take3-part1.patch, lucene-584-take3-part2.patch, 
> lucene-584-take4-part1.patch, lucene-584-take4-part2.patch, lucene-584.patch, 
> Matcher-20070905-2default.patch, Matcher-20070905-3core.patch, 
> Matcher-20071122-1ground.patch, Some Matchers.zip, Test20080111.patch
>
>
> {code}
> package org.apache.lucene.search;
> public abstract class Filter implements java.io.Serializable 
> {
>   public abstract AbstractBitSet bits(IndexReader reader) throws IOException;
> }
> public interface AbstractBitSet 
> {
>   public boolean get(int index);
> }
> {code}
> It would be useful if the method =Filter.bits()= returned an abstract 
> interface, instead of =java.util.BitSet=.
> Use case: there is a very large index, and, depending on the user's 
> privileges, only a small portion of the index is actually visible.
> Sparsely populated =java.util.BitSet=s are not efficient and waste lots of 
> memory. It would be desirable to have an alternative BitSet implementation 
> with smaller memory footprint.
> Though it _is_ possibly to derive classes from =java.util.BitSet=, it was 
> obviously not designed for that purpose.
> That's why I propose to use an interface instead. The default implementation 
> could still delegate to =java.util.BitSet=.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to