Actually, I'd write it like that last way even with the // operator. It's just a good habit to be in for cases where undef actually is a legitimate value. For example, in a standard get/set object method, knowing that nothing is passed in (read-only) is a very different case from undef being passed in (setting the value to undef). Of course, I can't see using the ternary operator in that precise situation, just that it's an easy way to see the difference between no parameter and undef as a parameter.

Of course, there are times where I don't want undef as a valid value - but I want my use of // to be an explicit statement that undef isn't allowed rather than an unintentional default.