[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.
