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.

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.

--
Dmitry Olshansky

Reply via email to