Working functionally with third party libraries

[via Digitalmars-d-learn]

On Thursday, 16 July 2015 at 20:41:21 UTC, ZombineDev wrote:
> On Thursday, 16 July 2015 at 20:17:54 UTC, Jarl André Hübenthal 
> wrote:
>> On Thursday, 16 July 2015 at 20:00:38 UTC, Ali Çehreli wrote:
>>> On 07/16/2015 12:35 PM, "Jarl 
>>> =?UTF-8?B?QW5kcsOpIEjDvGJlbnRoYWwi?= <jarl.andre at gmail.com>" 
>>> wrote:
>>>> Hi
>>>>
>>>> using mongo with vibe.d is easy. But I would like to skip 
>>>> the foreach on
>>>> MongoCursor?
>>>>
>>>> I mean, I want to use map!, filter! and reduce! on the 
>>>> resulting docs.
>>>> Is there a fast way to convert MongoCursor to an array 
>>>> without resolving
>>>> to ugly for loops with appender! ?
>>>
>>> I've never used MongoCursor but judging from the fact that it 
>>> has empty, front, and popFront(), it is an InputRange:
>>>
>>>   http://vibed.org/api/vibe.db.mongo.cursor/MongoCursor
>>>
>>> Have you tried using it with map and others? What errors do 
>>> you get?
>>>
>>> Ali
>>
>> Ah well I got another error now. Using the following code:
>>
>> 	Resource[] getResource() {
>> 		auto coll = client.getCollection("app.resource");
>> 		return coll.find().map!(doc => deserialize!(BsonSerializer, 
>> Resource)(doc));
>> 	}
>>
>> I get this error:
>>
>> src/app.d(51,21): Error: cannot implicitly convert expression 
>> (map(coll.find())) of type MapResult!(__lambda1, 
>> MongoCursor!(Bson, Bson, typeof(null))) to Resource[]
>
> Most of the functions from std.algorithm and std.range return a 
> lazy range which you need to iterate over go get its elements.
> To turn those ranges to an array you need add a .array at the 
> end (http://dlang.org/phobos/std_array#array). Here's a larger 
> example: http://d.readthedocs.org/en/latest/introduction.html.
>
> Another option is to return the elements as a range (by making 
> return type of your function auto), instead of putting them 
> into a newly allocated array (with .array). This way may be a 
> bit more work (delaying the call to .array), but it can be 
> quite efficient because it removes the need to allocate memory.

Thanks. Its a lot more cleaner and syntactically readable having 
.array at the end. But about laziness the same applies to clojure 
and scala. In clojure you must force evaluate the list, in scala 
you must to mostly the same as in D, put a toList or something at 
the end. Or loop it. But its pretty nice to know that there is 
laziness in D, but when I query mongo I expect all docs to be 
retrieved, since there are no paging in the underlying queries? 
Thus, having a lazy functionality on top of non lazy db queries 
seem a bit off dont you think?