Datasheet

Expressions, Not Statements
x
27
Of course, now that the situation has reversed itself, if the programmer does want the ability to
modify the internals of an object, the programmer must explicitly mark the parts of the class that
need to be mutable:
// This is not legal C# 3.0
class Person(firstName, lastName, age : int)
{
member FirstName = firstName;
member LastName = lastName;
mutable member Age = age;
member FullName = FirstName + “ “ + LastName;
override ToString() {
return String.Format(“{0} {1} {2}”,
FirstName, LastName, Age);
};
}
This will not be enough to make the world safe for multiple threads of execution, but it will reduce
the amount of thinking required to write thread-safe code.
EXPRESSIONS, NOT STATEMENTS
While the language syntax and semantics are up for discussion, an inconsistency within the tra-
ditional imperative language presents itself for possible correction: Certain constructs within
the imperative language are expressions, yielding a result value, while other constructs are state-
ments, yielding no value whatsoever. And in some languages, particularly those descending from
the C++ wing of the language family tree, the ultimate inconsistency presents itself: Two differ-
ent language constructs that do almost the same thing, except that one is a statement and the
other an expression:
var anotherResult = false;
if (x == 2)
anotherResult = true;
else
anotherResult = false;
var yetAnotherResult = (x == 2) ? true : false;
The inconsistency is maddening. Particularly when it could be applied to a variety of other con-
structs — why doesn’t switch/case have a similar kind of expression construct?
var thirdResult =
switch (x)
{
case 0: “empty”; break;
case 1: “one”; break;
case 2: “two”; break;
default: “many”; break;
};
c01.indd 27c01.indd 27 10/1/2010 3:20:39 PM10/1/2010 3:20:39 PM