gistfile1.txt

comments of blog post 'The Selector Pattern'

Lets assume that we will use your original select method. In all use cases I can think of there will be only one canonical implementation of this abstract method. Canonical implementation for the List interface will consist of cons and nil. In my opinion all lists will be built from nil and cons, so you don't need an easy way (i. e. lambda-expression) to override select.

I've created an adt4j package bases on similar ideas: https://github.com/sviperll/adt4j

I agree, Lambda expressions as an easy way to implement cons and nil, is not something required. It's just fun.
I'm more interested by the relation that says that there is a bijection between an ADT and a function and the properties of such function. From a language designer/implementor perspective, it means that you can encode an ADT to a function without any supplementary mechanisms.

I believe the implementation of flatMap is incorrect. Given:

List list = cons(1, cons(2, cons(3, nil())));

then:

list.flatMap((i) -> cons(4, cons(5, nil()))).size()

should be 6, imho, but the current implementation gives 2.

I haven't been able to write an implementation that gives 6 yet, so I'm curious to see how it can be done.

yes, it should be fixed now so
list.flatMap((i, tail) -> cons(4, cons(5, tail))).size()
should work !

• This comment is for testing github.io blog commenting.