split lambda

[GoogleCodeExporter]

lambda class appear to be too large. i think that is better split in some
classes with sigle responsability.

i want create a package lang inside lambdaj with one class per responsability:
 * ch.lambdaj.lang.Join
 * ch.lambdaj.lang.Select
 * ch.lambdaj.lang.Filter
 ...

Original issue reported on code.google.com by luca.marrocco on 9 Jan 2009 at 10:44

[GoogleCodeExporter]

It sounds a good idea, but I would like to better define the features that each
responsibility should cover before. For example, as I replied to the issue 2, 
the
difference between select and filter is not clear.

Original comment by mario.fu...@gmail.com on 19 Jan 2009 at 8:40

[GoogleCodeExporter]

it's right. filter is an alias of select.. or viceversa

Original comment by luca.marrocco on 20 Jan 2009 at 3:37

[GoogleCodeExporter]

Original comment by mario.fu...@gmail.com on 26 Jun 2009 at 7:10

• Changed state: Accepted

[GoogleCodeExporter]

Hi,

Splitting Lamdaj class can be a good and bad idea. It is a facade, so it is
reasonable to be very big class. Splitting them, IMHO, could decrease the Lamdaj
usability.

Original comment by filosgan...@gmail.com on 27 Jun 2009 at 1:11

[GoogleCodeExporter]

I agree with filosganga80, it can be good and it can be a bad idea. Mockito 
uses the
same facade strategy; one large "entry point" class with static methods for all 
(or
at least most of) the features of the library. In Eclipse I can set up
ch.lambdaj.Lambda as a "favorite" for static import lookups, meaning I get code
completion by just typing in the method names. If the Lambda class is split up, 
I
must set up more classes as "favorites".

Original comment by flobakk on 16 Sep 2009 at 7:20

[GoogleCodeExporter]

my suggestion is to divide lambdaj logic internally
 * ch.lambdaj.lang.Join
 * ch.lambdaj.lang.Select
 * ch.lambdaj.lang.Filter

and have a facade ch.lambdaj.LambdaJ that remain the entry point of the 
functionality.

Original comment by luca.marrocco on 16 Sep 2009 at 7:25

[GoogleCodeExporter]

I agree that splitting the Lambda class will make the library less usable.
Moreover the class ch.lambdaj.Lambda is already not much more than a facade that
calls the features internally implemented by lambdaj. In other words each 
method of
the Lambda class is typically one or two line of codes, so I don't see a need to
create another layer of delegation.

Original comment by mario.fu...@gmail.com on 10 Oct 2009 at 3:57

• Changed state: WontFix