lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <>
Subject Re: The distinction between a Wrapper and a Filter
Date Thu, 15 Nov 2012 13:16:04 GMT
I'm not sure that we should follow because the IO package doesn't
e.g. filter bytes, so maybe the name FilterInputStream made sense to
someone at some point (it doesn't to me). But also, in Lucene we already
have Filter which is recognized as filtering documents, and hence was my
confusion - that another Filter* class would filter out some data too.

I feel that Forwarding makes me exhale a lot of air, as opposed to *Wrapper
Naming is not easy, but as long as the names are consistent with the
object's behavior, I won't stand in the way of
Forwarding/Wrapper/Delegator/Decorator ...


On Thu, Nov 15, 2012 at 3:05 PM, Adrien Grand <> wrote:

> Hi,
> On Thu, Nov 15, 2012 at 11:52 AM, Shai Erera <> wrote:
>> Several objects introduce a Filter/Wrapper, which essentially act as
>> delegators. E.g. FilterDirectory, FilterCodec, FilterAtomicReader, and
>> while not strictly a delegator - SlowCompositeReaderWrapper.
>> I would like to rename all the above Filters to Wrappers, e.g.
>> DirectoryWrapper, CodecWrapper and AtomicReaderWrapper, b/c I think that
>> better reflects what they do. *Delegator is less preferable, but I'm
>> willing to live with it too.
> On the one hand I think it is good to use the same naming convention for
> our decorators as the API (see FilterInputStream[1] docs for
> example) but on the other hand I was confused too when I first read about
> these classes, so I would be supportive if we decide to change the naming
> convention for 5.0. Maybe we could use something more descriptive than
> *Wrapper? (I personally like Guava's naming convention to prefix their
> decorators by "Forwarding".)
> [1]
> --
> Adrien

View raw message