Deferred Execution

[GoogleCodeExporter]

This is not an issue as much as this is a discussion.
I notice the usage of List<> as the return value of the operations. Am I 
correct to assume that the operations are done immediately?

The best thing about lambda (as a mathematical concept, as well as programming 
feature in Linq) is its piped (i.e. deferred) nature of its execution.
In the original Linq in .net for example, linq operations takes and returns 
IEnumerables<> (aka c# "yield"), which means that when you call 
select/where/join/union etc, it's not doing anything or giving you any item. 
As you enumerate the IEnumerable, each item will be piped from one operation to 
another, giving you a stream of items within the iteration.

E.g. you can open and read the content of a file, tokenize it into words, and 
performs "select", then "where" it, then "join" it etc. You pass around your 
IEnumerable<> instances from one linq operation to another, at no cost. Each 
operation doesn't read/filter any content of your file.
It will only execute the actual reading of the file as you enumerate the items, 
and only as a single iteration.
So if you have a large file, it will not bring the whole content to the memory.

Could anyone clarify if this is what LambdaJ does? The use of List<> in its API 
suggests that it's not.
I also think that some sort of "yield" API would be a great supplement for 
LambdaJ API as an easier way to work with Java's iterator.

Original issue reported on code.google.com by hendrym...@gmail.com on 7 Feb 2011 at 5:43

[GoogleCodeExporter]

Sorry, I think I might have marked this as a defect by mistake.

Original comment by hendrym...@gmail.com on 7 Feb 2011 at 5:44

[GoogleCodeExporter]

I also read on the performance-analysis section, but couldnt find an example 
where it does something like "contains" or "any" or "first" or "isEmpty" 
operations. Performing these operations after something like select/where/join 
will incur huge performance cost as all those operations will be iterating the 
whole list where only a small portion of it is eventually needed.

Original comment by hendrym...@gmail.com on 7 Feb 2011 at 5:50

[GoogleCodeExporter]

Original comment by mario.fu...@gmail.com on 24 Apr 2011 at 3:21

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Where possible, some lambdaj operations like conversion, extraction and 
selection already have a lazy form returning an Iterator instead of a List. See:

http://lambdaj.googlecode.com/svn/trunk/html/apidocs/ch/lambdaj/Lambda.html#conv
ertIterator%28java.lang.Object,%20ch.lambdaj.function.convert.Converter%29
http://lambdaj.googlecode.com/svn/trunk/html/apidocs/ch/lambdaj/Lambda.html#extr
actIterator%28java.lang.Object,%20T%29
[http://lambdaj.googlecode.com/svn/trunk/html/apidocs/ch/lambdaj/Lambda.html#sel
ectIterator%28java.lang.Object,%20org.hamcrest.Matcher%29

Original comment by mario.fu...@gmail.com on 24 Apr 2011 at 3:38