The new std.process is ready for review

Jonathan M Davis jmdavisProg at gmx.com
Sun Feb 24 01:53:03 PST 2013


On Sunday, February 24, 2013 13:35:31 Dmitry Olshansky wrote:
> 24-Feb-2013 13:17, Jonathan M Davis пишет:
> > On Sunday, February 24, 2013 13:06:00 Dmitry Olshansky wrote:
> >> 24-Feb-2013 12:05, Andrei Alexandrescu пишет:
> >>> On 2/24/13 6:26 AM, Andrej Mitrovic wrote:
> >>>> Phobos modules which already use std.process would have to be changed
> >>>> to directly import std.process1 or std.process2.
> >>> 
> >>> This is problematic as has been discussed. I think we could address
> >>> immediate needs by attaching an attribute to import, e.g.:
> >>> 
> >>> @"v2.070+" import std.process;
> >>> 
> >>> or similar. By default code would import the old library.
> >> 
> >> The same could be achieved by simply using old version of
> >> compiler+druntime+phobos to compile old project.
> >> 
> >> I don't get the desire to keep old junk forever. A year or two - maybe.
> >> More then this is just insane.
> > 
> > I agree, but it _is_ more than a question of keeping old junk around in
> > this case. We need a we to transition cleanly, and the only way at
> > present that that means not breaking code is to put the new std.process
> > somewhere other than std.process, since if we put it in std.process, it
> > would mean breaking a lot of code which uses the current std.process,
> > forcing everyone to stick with the old compiler until they'd updated
> > their code. And we don't want that.
> I suppose it's easy to translate any active project (as in maintained)
> to the new std.process, as it's supposed to have easier/richer interface.
> 
> Then any old cruft that just works and there is no need to touch it can
> just use the older version of _compiler_. In any case the phrase "old
> code that needs to use new std.process" is kind of perplexing.

It's the fact that you're forced to update your code when you update the 
compiler rather than giving you time to update it which is the problem. I'm 
not completely against the idea of saying that we have the old std.process in 
one version and the new std.process in another - especially if we had more of 
a major-minor versioning scheme where it was expected that code would break at 
major version changes, but we don't really have that right now, and I really 
don't think that Walter would go for it anyway.

Long term, code should definitely be ported over to the new std.process, and 
it's probably not all that big a deal in this case (though other modules in 
similar situations could be a much bigger deal - e.g. std.date -> std.datetime 
was a very large change), but the question is whether it's okay to force 
people to change their code immediately. If it's not (and given Walter's 
attitude and our current versioning scheme, I don't think that it is), then we 
need to come up with a new name for the new std.process module rather than 
replacing it in-place. But it _is_ this sort of change which would make it 
desirable to adjust our versioning scheme.

> > Whether the old std.process sticks around for more than a year or two is
> > therefore a separate matter from what we name the new std.process unless
> > we
> > add a feature like Andrei is suggesting.
> 
> Maybe I'm missing something but I don't see this feature solving
> anything yet.

It makes it so that you can have both the old and new std.process be name 
std.process. However, given that @"v2.064+" or whatever would have to be there 
to use the new std.process and the fact that you'd presumably would want to 
remove it once the old std.process was actually gone, it's ultimately not all 
that different from naming it std.process2 and then renaming it to std.process 
later. It's just an attribute rather than a 2 at the end of its name.

- Jonathan M Davis


More information about the Digitalmars-d mailing list