The new std.process is ready for review

Vladimir Panteleev vladimir at thecybershadow.net
Mon Feb 25 11:38:58 PST 2013


On Monday, 25 February 2013 at 19:28:33 UTC, Lars T. Kyllingstad 
wrote:
> My reasons were what I said in my other post:  In the time I 
> have been using the 'environment' API -- that is, for 2 1/2 
> years (I checked) -- I don't think there is a *single* time 
> when I've chosen environment[var] over environment.get(var, 
> null).
>
> The thing about the process environment, as opposed to an 
> associative array inside your own program, is that you can 
> never be certain which variables are defined and which aren't.

Indeed. If a program expects a variable to be set when it isn't, 
the program should fail. Throwing in opIndex is one way to 
implement that.

> This means that you will almost *always* have to check whether 
> a variable exists before using it, thus rendering opIndex() 
> pretty much useless for most cases.

Check... and do what? Print a nicer error message?

> Furthermore, I really don't think it is too much to expect that 
> a user of a systems language such as D checks the return values 
> of functions that may return a 'null' value.

Expecting any sorts of things from the library user is not the 
way to go. It is the same reason why returning integer error 
codes has gone by way of history in favor of exception handling: 
checking all return values is cumbersome, it requires writing 
more code, many programmers don't do it, and the result is bad 
programs. The simplest code should also be correct, this is one 
of D's principles.

>> Speaking of shells, I noticed you hardcode cmd.exe in 
>> std.process2. That's another bug, it should look at the 
>> COMSPEC variable.
>
> Thanks, I didn't know that.  On POSIX, the -c switch is 
> standard, and works on most, if not all, shells.  Can we assume 
> that /C is equally standardised on Windows shells?

I believe so.


More information about the Digitalmars-d mailing list