On Friday, 18 September 2020 at 22:02:07 UTC, aberba wrote:
[...]
That's what I was trying to answer. When Steve said meh, he
probably didn't get what I said. Probably its because of my
typos.
This sort of convenience and productivity benefit is part of
why I use Node.Js in the job when I need to get things
done....and not D yet. There are several pieces and bits you
can't write yourself when working on projects.
In this case you want to get the file(s) in memory...in the
form of bytes (or buffer) and probably set a file size limit.
Its all doable through a library but such a library doesn't
exist in D yet. At least not that I know of.
Yes it would be convenient and thanks for the links but since I'm
not familiar with Node.js at all parsing the input myself will be
better than getting into Node.
Vibe.d still lacks many things I personally need... there's
simply not enough ecosystem third-party libraries.
My first impression of vibe.d is that the author(s) made a
presumptions about the one way things should be done(tm) and if
that's not your use case too bad for you.
That's where most of my displeasure of using vibe.d comes from
and that those aren't described in the documentation - not so
much because of the things that aren't implemented (yet).
Handling file uploads is one example, another is command line
arguments.
The presumption here is there is vibe and there can only be vibe.
It takes them from Runtime.args. Duh?
This didn't make sense to me until I saw example where the
initialization of vibe was done in a module constructor.
Looks cool on a cursory look but is incredibly impractical if you
don't want to do it that way. And that's the gist - vibe.d is
incredibly impractical if your use case doesn't exactly match the
author(s) assumptions of the one way to do things(tm).
And there are issues with that, too. E.g. in the example the
server will be started before command line args are completely
processed. That means if there are wrong or missing or extra args
the application aborts and leaks OS resources.
The way I would have implemented it is to take args from
Runtime.args by default but allow passing an args[] to a vibe
args-handler. I could then parse whatever args I'm interested in
in my favorite way and pass the rest to vibe.
But you can handle those with vibe getOption or some such - why
don't you want to do comandline args processing with vibe you ask
?
Because 1. there's std.getopt which is awesome, and
2. If I don't depend on vibe to parse them and I have a build
configuration with version="NO_SERVER" I don't even need to link
against vibe and its dependencies.
By using vibe I feel like I need to bend myself like a snake and
jump through the hoops of vibe's one way to do it. You save a lot
of time here and there and then you lose half a day because of
some stupid road block like the above.
