Devoxx - filter, partition and offset

William Clark wclark1324 at comcast.net
Wed Apr 3 19:37:27 PDT 2013


Add to that Python:
http://docs.python.org/2/library/functions.html#filter

and the JDK itself uses filter in the same sense for a few types:

http://docs.oracle.com/javase/6/docs/api/java/util/logging/Filter.html
http://docs.oracle.com/javase/6/docs/api/javax/swing/RowFilter.html
http://docs.oracle.com/javase/6/docs/api/javax/swing/filechooser/FileFilter.html 
(and FilenameFilter)

The JDK is explicit in at least one case I can think of: 
Collection.retainAll and .removeAll. Maybe someone else can think of an 
example where the JDK uses filter in the less common sense? (the 
left-handed analogy was quite apt.)

-William

On 4/3/2013 5:50 PM, Jed Wesley-Smith wrote:
> On 3 April 2013 22:36, Stephen Colebourne <scolebourne at joda.org> wrote:
>> It didn't come up in the Devoxx lab, but I found the filter() method
>> confusing when reading code in the talks. It was not obvious to me
>> whether it was filtering in or out.
>>
>> I was then surprised that there was only one method in the API for
>> filtering, rather than two - one to remove and one to retain. While
>> clearly they are a logical not, in code readbility terms its typically
>> a lot clearer.
>>
>> Perhaps keep() and reject()? I'm sure there are other names, but
>> filter alone feels very unclear. (I can't remember which it is now).
> Haskell:
> http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-List.html#v:filter
>
> Scala:
> http://www.scala-lang.org/api/current/index.html#scala.collection.immutable.List
>
> Standard ML:
> http://www.standardml.org/Basis/list.html#SIG:LIST.filter:VAL
>
> Erlang:
> http://www.erlang.org/doc/man/lists.html#filter-2
>
> Guava:
> http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Iterables.html#filter(java.lang.Iterable,
> com.google.common.base.Predicate)
>
> Wikipedia:
> http://en.wikipedia.org/wiki/Filter_(higher-order_function)
>
> all define the same behaviour and name of this method.
>
> It is sufficiently commonplace that to define it differently would be
> arbitrary and random.
>
> cheers,
> jed.
>
>



More information about the lambda-dev mailing list