Whether or not a Schwartzian Transform was warranted was beside the point. I was just using that to demonstrate autoboxing. Though I have to confess that, while really cool, I can't see any use for autoboxing. I was hoping that someone would whip up a killer app and convince a sceptical world that they can't do without this, but I doubt I'll see that happen (and curiously, even in the arguments that I've seen in favor of autoboxing, I've not seen anyone post code).

OK, so this may not be a "killer app", but one feature of autoboxing can be really a time-saver: methods on undef

I like chaining methods, and often I am only interested in the result of the whole chain. For example when navigating an XML document: $elt->first_child->text or $doc->root->last_child( 'section')->first_child( 'title')->att( 'num'). If one of the calls fails, than I am happy with undef being returned. I just don't like having to test every single method call. Which is often what I have to do, or the program dies when it tries calling a method on undef.

None of the possible alternatives seems to be as convenient as autoboxing undef, the closest in convenience, but I would guess at a higher performance price, being by returning a pre-defined object instead of undef in case of failure and overloading the boolean-ification of the object.

That sounds like a good use of the Null Object pattern.

I think this is a problem best left unaddressed. In general OO the Law of Demeter forbids such deep hierarchy navigation constructs.

Now, manipulating XML (or other document) structures is a very specific case, and not all the common OO rules necessarily apply. However, I'd argue that this means you should rather be using a language addressed at this specific problem domain. Which in this case does exist and should be obvious: XPath. Indeed, something like this behaves exactly the way you specified:

# LibXML lingo; XPath expr is off the cuff, untested
$doc->findvalue('/section[last()]/title[1]/@num');
[download]

All that said, even methods on undef would not really solve the issue, just sweep it under the rug. Doing this well and cleanly in Perl would require something along the lines of

$doc->root(sub {
    $_->last_child( 'section', sub {
        $_->first_child( 'title', sub {
            $_->att( 'num')
        })
   })
});
[download]

In summary, you will not be able to solve this satisfactorily and concisely in a language without continuations. Which isn't so bad, because this particular problem is likely better left unsolved.

Makeshifts last the longest.

Could you get around that by just doing eval{ $child->parent->grandparent->bar()} if($@){} And check $@ for 'method on undef' or whatever the exact string is?

Another alternative:

eval {
  $some->big->chain->of->calls
}
die $@ if($@ 
  && $@ =~ /\^Can't call method .* on an undefined/)
[download]

Add sugar to your taste

(Or Perl6's undef but ?something?;)