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