I prefer to place the ‘var’ where the variable is first defined, but this is misleading to anyone coming from Java (or practically any other language), so it’s a real trade off.

(I also prefer to treat variables as read-only except where there loop indices, which somewhat mitigates the problem, at least.)

[blockcode]
var product = …;
if (product) {
var offering = product.offering;
if (offering) {
var merchant = offering.merchant;
if (merchant) {
var merchantName = merchant.name;
if (merchantName)
displayMerchantName(merchantName);
}
}
}

… the in the best case scenario, those “local” variable declarations add variables to the local function’s scope, or in the worst case scenario, if you write this type of code at the top level, those “local” variables will pollute the global namespace.
[blockcode]

These typos happen to exactly illustrate my point — that when you add a temporary variable just to get a value from one line to the next, you’ve introduced an error site — but I won’t pretend that I did this on purpose. I’ve fixed these (I think) now.

So your example would be:
product.?offering.?merchant.?name

Java’s really the language that needs a better solution for this. I think a lot of Java programmers don’t use null values because it’s so hard to express the intended semantics without building your own type annotations and such. The proposal for Javascript where nullable types are different from non-nullable ones makes a lot of sense to me.

my $name = eval { $product->offering->merchant->name };

To keep with reduce, it would have to be something like $a && $a->$b() as the reduce block.

my $name = (
reduce { eval { $a->$b() } }
$product,
qw( offering merchant name ),
);

display_merchant_name($name) if defined $name;

def merchantName(maybeProduct: Option[Product]) : Option[String] =
for (val product <- maybeProduct ;
val offering <- product.offering;
val merchant <- offering.merchant)
yield merchant.name
}

def merchantName(maybeProduct: Option[Product]) : Option[String] =
for (val product


the_dormant: Okay, that does it. I’ll finally at scala.

Alan, Thomas, thanks for the comments. Something that makes me uncomfortable about catching exceptions is that it has dynamic scope. If the accessors don’t run any code, it’s the same thing, but if product.offering is a getter that includes the expression record.connection, then the rescue will hide the case where record is null, as well as the case where product is null.

Alan: After I wrote this I found this post http://weblog.raganwald.com/2007/04/writing-programs-for-people-to-read.html on Raganwald, which covered the “narrative mismatch” earlier and better. Braithwaite summarizes a post by Norbert Winklareth as being about “minimizing the semantic distance between the program as written and the solution to the problem as conceived by the programmer”.