The new std.process is ready for review

Lars T. Kyllingstad public at kyllingen.net
Sun Feb 24 06:43:49 PST 2013


On Sunday, 24 February 2013 at 04:54:13 UTC, Jonathan M Davis 
wrote:
> On Saturday, February 23, 2013 19:47:54 Nathan M. Swan wrote:
>> 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.
> [...]
> 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.

Let me save you the trouble.  There are three points of 
incompatibility between the old and the new APIs, that prevent 
them from coexisting:

shell():

The old shell() captures the standard output, returns only a 
string containing the output, and throws an exception if the 
program returns with a nonzero exit code.

The new shell() only throws if there was an error with actually 
running the process, it captures both the standard output AND 
standard error streams, and it returns a tuple which contains 
both the output and the exit code.

environment.opIndex():

The new version no longer throws if the environment variable does 
not exist, it simply returns null.  This is a very subtle change 
that will not cause a compilation error.

It was I who wrote the old 'environment' as well, and the idea 
was for it to have the exact same interface as the built-in 
associative arrays.  Therefore, at the time, it seemed like a 
good idea to throw from opIndex().  However, having actually used 
it for quite some time, I have found that I *never* want that 
functionality.  I *always* end up calling environment.get() 
instead, to avoid the exception.  Thus, I decided use this 
opportunity to change it.

environment.get():

To distinguish it from opIndex(), the second argument (the 
default value if the variable doesn't exist) is no longer 
optional.  This, however, will cause a compilation error in the 
cases where the second argument has been left out, and all other 
cases will work like they used to.


I would absolutely *hate* to have to change the name of shell(), 
or, worse, revert it to the old version.  I am reluctant to 
revert environment.opIndex() too, as I would really like to get 
it right this time.  I am not going to be as adamant on this, 
however.  environment.get() is not a big deal, but if 
environment.opIndex() changes, this might as well do too.

Lars


More information about the Digitalmars-d mailing list