The new std.process is ready for review

[Jonathan M Davis]

On Saturday, February 23, 2013 19:47:54 Nathan M. Swan wrote:
> Jonathan M Davis wrote:
> > On Saturday, February 23, 2013 18:39:10 H. S. Teoh wrote:
> >> Alternatively, I would push for renaming the old std.process to
> >> something like old.process (or something else), which is much less of a
> >> breakage than deleting it from Phobos outright -- existing code just
> >> need to have their imports fixed and will continue working, whereas
> >> deleting the module outright leaves existing code with no recourse but
> >> to potentially rewrite from scratch. This may be easier to convince
> >> Walter & Andrei on, than outright killing old deprecated modules.
> > 
> > Possibly, but Walter takes a very dim view on most any code breakage, even
> > if it means simply changing a makefile to make your code work again, so
> > I'd be very surprised if he thought that moving the current std.process
> > would be acceptable. If Andrei could be convinced, then we could probably
> > do it, but I wouldn't expect him to agree, and IIRC, he had no problem
> > with the std.process2 scheme and might even have suggested it. So, I
> > suspect that your only hope of avoiding std.process2 is if you can come
> > up with a better name.
> > 
> > - Jonathan M Davis
> 
> Why not just deprecate everything currently in std.process and drop in
> the new stuff? It might be a bit ugly, but it prevents both code
> breakage _and_ a proliferation of "std.module2"s.

That only works if there are no conflicts and none of the functions' behaviors 
are changed in a manner which would be incompatible with how they currently 
work. We _were_ able to do exactly what you're suggesting with std.path, but 
it isn't always possible. std.random would be a prime case where it would be a 
problem, because one of the main changes that we want to do is translate all 
of its structs into classes, which would break a lot of code, and wouldn't be 
compatible at all - not unless you come up with new names for everything, 
which would be downright ugly. I don't know how much the new std.process 
conflicts with the old one, but since the main fellow behind the new one is the 
same one who did the new std.path, I suspect that they conflict to much to be 
able to do the transition within a single module. I'd have to compare them to 
be sure though.

- Jonathan M Davis