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
