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.
