Hi Clause, Albert, and all,
Since the introduction of lambdas in Java 8, Java has a well-defined
terminology around the classic producer-consumer paradigm but (for
reasons unknown to me) realized in the functional interfaces *Supplier
and *Consumer. In addition, as of Java 5, we have the Iterable
interface.
In our new Bloom filter package we have new interfaces called
*Producer (as opposed to *Supplier), where some of these new
interfaces are formally annotated with @FunctionalInterface and some
not (for example, BloomFilterProducer).
My question is: Why call these "Producers" instead of "Suppliers"? Is
the formal Bloom filter literature tied to the "Producer" terminology
in a way that would make adapting to the Java term confusing? I know I
brought up a similar topic recently, but I would like to revisit it
now that I've started to read Claude's blog drafts. Even without
making the current "Producers" formal suppliers by extending Supplier,
would it be worth using the Java terminology?
My second observation is that some might neither be "Producers" or
"Suppliers" but instead be extensions of Iterable. For example,
BitMapProducer is not a factory for instances of BitMap; the BitMap
does not appear in the signatures of BitMapProducer methods. From a
strict Java POV, this is (slightly) perplexing.
Instead (forgetting the class name issue for now), we could have:
@FunctionalInterface
public interface BitMapProducer extends Iterable<LongPredicate> {...}
Which would let implementations define:
Iterator<LongPredicate> iterator();
Instead of:
boolean forEachBitMap(LongPredicate predicate);
Same comment for IndexProducer.
Same comment for BloomFilterProducer.
Is this too much Java-ness?
CellConsumer looks like a Predicate, not a traditional Java *Consumer.
We have a specialization called LongBiPredicate so I propose we rename
and extract CellConsumer as IntBiPredicate.
TY!
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
