On 10/29/13 11:16 AM, Lars T. Kyllingstad wrote:
Since I was the one who added the deprecation notices, I guess I'll have
to answer for it. :)
Great, thanks.
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?
While I have no statistics to back this statement with, the very fact
that std.process went through several reviews on this forum and the
Phobos mailing list, and even went into active use by some people (and
one notable project, vibe.d) long before its inclusion in Phobos,
without these functions being mentioned even *once*, is testament to its
accuracy.
It's been indeed reviewed, and I followed the reviews and was glad to
see people liked it. My understanding was it was a backward compatible
(within reason) revamp of std.process. It honestly didn't occur to me to
go and see whether essential existing functionality has been deemed
deprecated.
To me, these functions simply fall on the wrong side of the
usefulness/bloat line.
On usefulness: "Objection, your honor" :o). Forwarding from one process
to another is an essential part of process control. Loading another one
and waiting until it's done is a very wasteful way to replace it. And I
do recall the std.process revamping took pride in being more efficient
than the old one.
On bloating: the module std.process defines a couple dozen symbols. It's
very far from bloating, and unlikely to grow because OSs are fairly
stable when it comes to process control. Bloating doesn't strike me as a
valid argument for removing existing useful and relevant functionality.
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.
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.
Andrei
P.S. Also found this: "abstract final class environment". What happened
to the naming conventions? Shouldn't that be capitalized?
