On Tuesday, 29 October 2013 at 19:13:28 UTC, Andrei Alexandrescu
wrote:
On 10/29/13 11:16 AM, Lars T. Kyllingstad wrote:
[...]
The main rationale for removing them was that I considered
them to be
low-level, rarely used functionality. Most applications *by
far* will
use the "spawn" style of process creation.
That would be reason to not add, not to remove. They're there,
and I must use them, otherwise my D code is 10% slower than the
equivalent C++ code, in a project at work in which speed is of
the essence. Why do I need to resort to the C functions?
Even if you don't buy my arguments, I think Vladimir's point
about exec*() basically being POSIX specific, and nothing more
than a hack on Windows, is an even stronger argument.
You are doing platform-specific stuff, so you should resort to
platform-specific libraries. Were it up to me, I'd remove them
from std.c too, forcing users to import core.sys.posix.unistd
instead.
[...]
On usefulness: "Objection, your honor" :o). Forwarding from one
process to another is an essential part of process control.
It is apparently not essential enough for it to be natively
supported on Windows.
Loading another one and waiting until it's done is a very
wasteful way to replace it. [...]
I'm not suggesting this as a solution for you, but let me just
point out that you wouldn't have to wait until it's done. You'd
spawn it and exit. On Windows this is, as Vladimir points out,
exactly what happens when you call exec*(). On POSIX it comes at
the cost of a fork() (which I completely agree is unacceptable in
some situations).
[...]
And to quote http://dlang.org/phobos/,
"No pointless wrappers around C runtime library functions or
OS API
functions. [...] Pointless D wrappers around those functions
just adds
blather, bloat, baggage and bugs."
This quote is thoroughly misapplied. A pointless wrapper is a
one-liner. Writing a passable wrapper for exec* is quite a bit
more involved.
Ok, I'll give you that.
That said, they are not actually deprecated yet (as in marked
with the
"deprecated" attribute), so if the community wants them back,
it is a
simple matter of removing the deprecation notices.
I hope I provided compelling arguments.
Nope, I don't think so. :)
That said, I know that there are completely legitimate uses for
exec*(), and I have no doubt yours is one. I also agree that the
fact that the functionality is already there is an argument
against removing it.
Therefore, I would like to suggest a compromise: I propose we
move the functions into an std.posix.process module. (There is
currently no std.posix package, but we do have std.windows, so I
don't see why we can't add it.)
P.S. Also found this: "abstract final class environment". What
happened to the naming conventions? Shouldn't that be
capitalized?
Seems I'm the culprit again. :) The rationale is: It walks like
a variable, it talks like a variable, so let's name it like a
variable. The semantics of "environment" are those of a global
variable (of a noncopyable associative-array-like type), and the
fact that it's actually a class is an implementation detail.
Btw, environment has been in std.process for ages; it was not
part of the revamp. (Or rather, it was a part of the revamp that
got integrated years before the rest.)
Lars
