On 10/29/13 1:25 PM, Lars T. Kyllingstad wrote:
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.
I think that's the weakest argument of the lot, see the rebuttal in my
answer to it.
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.
It's Posix, and Windows also implements the family. Not an argument for
removal that Windows implements it in a suboptimal manner.
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.
That's a good point. Nevertheless there are deeper reasons for that. Far
as I can tell functions like fork() and exec() are tenuous on Windows
due to the way it's architected, so they favor other ways to go about
things. Then they also took the time to implement exec(). No fault
there. Just don't make it difficult to get to it.
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).
Interesting, I'll do that. But my point here remains: there is no lower
bound in the speed I need.
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. :)
Then we have a problem. Because I am convinced I am copiously right, and
you failed to make any comparable argument to the contrary. To me the
only matter to deal with is my being annoying when I know I'm right.
(That may, in fact, be the bigger problem because I can be mightily
annoying.)
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.)
I can only assume Windows made a bona fide effort to make their _exec()
implementation
(http://msdn.microsoft.com/en-us/library/vstudio/431x4c1w.aspx) as good
as possible within the design of that environment. I find it very forced
to insist on letting that go to waste and moving exec() to Posix just
because... I honestly don't know why. There was no good argument in
favor of going any other way but fixing the mistake of deprecation.
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.)
Well that's a bummer but not the focus of my ire.
Andrei
