The new std.process is ready for review

H. S. Teoh hsteoh at quickfur.ath.cx
Sat Feb 23 18:39:10 PST 2013


On Sat, Feb 23, 2013 at 05:32:08PM -0800, Jonathan M Davis wrote:
> On Saturday, February 23, 2013 20:14:14 Steven Schveighoffer wrote:
> > On Sat, 23 Feb 2013 20:07:43 -0500, Jonathan M Davis <jmdavisProg at gmx.com>
> > wrote:
[...]
> > > We might be able to remove std.process eventually and then rename
> > > std.process2 to std.process (leaving std.process2.d to import
> > > std.process), but Walter (and to some extent Andrei) seems to be
> > > very much in favor of leaving stuff around permanently. It's
> > > likely that std.process will be deprecated (which now defaults to
> > > warning about it rather than giving an error) and eventually
> > > undocumented, but actually killing it off may take a bit of doing
> > > given Walter's attitude about code breakage. He seems to be
> > > perfectly fine with leaving around old, dead code on the
> > > off-chance that some older code is using it and would break if it
> > > were removed.
> > 
> > I don't see std.date around anymore...
> 
> Yes. I killed it, but Walter has never liked that sort of thing and
> has been increasingly outspoken about it, and Andrei seems to be
> jumping on that bandwagon. For instance, IIRC, they both griped about
> actually removing the deprecated functions from std.string. I'd _very_
> much like to get rid of them outright, since they clutter the code and
> actually were generating errors when used until recently (since they
> were deprecated before the changes to deprecated). Keeping them around
> is just plain harmful IMHO, and I may yet manage to kill them off, but
> they don't seem to like the idea, and I fully expect a similar
> attitude towards something like std.process. Unfortunately, while
> replacing old solutions with new, better solutions seems to be fine,
> it doesn't seem to be okay to actually get rid of the old ones
> anymore.
[...]

Well, std.regexp got lucky, in that the new module has a subtly
different name std.regex, so we can just eventually stop documenting
std.regexp but leave it in the codebase for whatever old code that uses
it to continue working. Ditto with the upcoming std.io to replace
std.stdio.

But I can't think of any better name for the new std.process. :-( I'd
suggest std.proc, but I'm pretty sure it will get shot down as it's too
short and ambiguous (it could be misinterpreted as std.procedure for
example).

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.


T

-- 
There's light at the end of the tunnel. It's the oncoming train.


More information about the Digitalmars-d mailing list