"if (ptr == NULL)" is usually two instructions and an instruction pipeline flush. That sucks, but I can't even imagine what the processor ends up executing for the Ruby lambda callback. Slightly more readable code at what cost?
That's not a very good question, `if object == nil` will already be a pretty huge number of instructions in ruby.
Now if the question is "could you have this pattern compile down to little more than a null check", the answer is why not? A bit of flattening/inlining should be able to handle it correctly.
And in most fields, the gain in safety way outweighs the almost unnoticeable (against background noise) loss in efficiency.
The answer for C# and Java, which this issue was directed at, is no.
Email me if you want details.
I'm not sure what you're talking about, you focused on java and C# for odd and unknown reasons, TFA merely uses java as an example of syntactically heavy (or even missing) closures language to illustrate the pattern's gains and differences.
The other day, I saw this example on StackOverflow:
Person person = dataSource.getPersonById(personId);
if (person != null) {
person.setPhoneNumber(phoneNumber);
dataSource.updatePerson(person);
}If the canonical example under discussion is in Java, I think it is safe to assume the article is about Java.
No. The article is about a pattern of explicit null-check avoidance, java is an example of "a language without blocks or lambdas" but the article is no more about java than it is about ruby, you're not even missing the forest for the trees you're missing the forest for a fallen leaf.
Probably a lot more than the null-check, and yet still undetectable against the background of the db call.
If we keep adopting readability tricks with orders-of-magnitude differences in speed compared to what we're replacing, we'll just keep getting slower and slower code.
I think for most cases where what you want to do isn't throwing an error on null, most of the time null checks are addressing external interfaces (database or otherwise) where the IO is going to be enough bigger than the pattern overhead that if you are able to deal with the load from the basic functionality, the difference between null check and using this "teller" style implementation is going to be negligible.
And, obviously, where you want to error-on-null (whether or not an external interface is involved), this isn't the pattern to apply.
> If we keep adopting readability tricks
Factoring out commonly used boilerplate into a library function isn't a "readability trick", though it does benefit readability and maintainability of code.
And its safety and correctness.