Introducing vibe.d!

[Sönke Ludwig]

[my previous anwer got lost because of an high-load error on the NG 
server. hope I didn't forget anything..]

Am 27.04.2012 21:40, schrieb F i L:
> Sönke Ludwig wrote:
>> During the last few months, we have been working on a new
>> framework for general I/O and especially for building
>> extremely fast web apps. It combines asynchronous I/O with
>> core.thread's great fibers to build a convenient, blocking
>> API which can handle insane amounts of connections due to
>> the low memory and computational overhead.
>>
>> Some of its key fatures are:
>> ...
>
> vibe.d looks great! Looking through the docs, it feels clean and "hip"
> like node.js
>
> However, there are a couple refactoring choices I think would have made
> it even more "hip", consider the home page example:
>
> import vibe.d;
>
> void handleRequest(HttpServerRequest req,
> HttpServerResponse res)
> {
> res.writeBody("Hello, World!", "text/plain");
> }
>
> static this()
> {
> auto settings = new HttpServerSettings;
> settings.port = 8080;
>
> listenHttp(settings, &handleRequest);
> }
>
> "vibe.d" as the project name is great, but why have module vibe.d and
> not simply vibe? Or, why prefix all the types with "HttpServer" when you
> could separate those objects into a new module and drop the prefix. I
> think those simple changes would make an already polished library shine
> a bit brighter:
>
> import vibe.http;
>
> void handleRequest(Request req, Response res) {
> res.writeBody("Hellow, World!", "text/plain");
> }
>
> static this() {
> auto settings = new Settings;
> settings.port = 8080;
>
> listen(settings, &handleRequest);
> }
>
> the echo server would look like:
>
> import vibe.tcp;
>
> static this()
> {
> listen(7, (conn){ conn.write(conn) });
> }

The objects are already in different modules, albeit a level deeper 
(e.g. vibe.http.server). "import vibe;" cannot currently work without 
something like DIP15 or DIP16 because vibe is a package.
-> http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs

There are two reasons, why I made the names unique: 
readability/understandability and ease of use (not having to look up all 
the sub modules to find a certain function).

I am not really happy with the long names but on the other hand I found 
this was not really much of an issue, because often you can avoid it 
alltogether with things like staticTemplate!"file.dt" 
(http://vibed.org/api/vibe.http.server#staticTemplate) or by using a 
closure with inferred parameter arguments.

>
> Also, it's great to see MongoDB support built in :D, but isn't there a
> way to trim down the query object from:
>
> BSON({"name": BSON("Peter")})
>
> to:
>
> BSON({"name":"Peter"})
>
> by writing a generic AssosiativeArrayToBSON function? That way you could
> overload MongoDB's find/save/etc functions to accept arbitrary AAs as
> queries, which would end up looking a lot slicker in the docs I think.
> Plus, through CTFE it's possible this conversion could happen at both
> compile-time and run-time:
>
> auto db = new MongoDB;
> auto col = db["test.collection"];
>
> foreach (doc; col.ctFind!(["name":"Peter"])) {
>
> ...
> }

The MongoDB functions can actually take any of Bson, Json, 
Bson[ObjectID,Date,...], arrays, AAs, strings and scalars and structs 
and classes, in any nesting. They use serializeToBson() internally to 
convert to Bson.

The examples and the documentation need some updates there.

>
> Just some ideas in case you haven't thought of them already :)
>
>
> Overall vibe.d looks like a fantastic library. Thank you and Congrats!

Thanks! I hope the remaining rough edges get smoothed out quickly in the 
next time.