The new std.process is ready for review

Dmitry Olshansky dmitry.olsh at gmail.com
Sun Feb 24 01:35:31 PST 2013


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


More information about the Digitalmars-d mailing list