[mendicant]

There are certain languages and situations where the pattern does make sense. But as a heavy C# coder, I find that more often than not you're dealing with a class heavy codebase where it's more important that you _don'_ do foo()?.bar?.bing(). Specifically as things happen such as refactoring you often need to ask the question should something 'care' that a foo has a bar which has a bing. Perhaps if you want to know about a bing that is down the chain from Foo, perhaps Foo should provide you with the Bing somehow (which really helps with refactoring as codebases grow to years and potentially decades old).

It's not always so cut and dry, and there are situations where this is a very valuable tool. I just feel that down the road if you feel like there is a valid reason for refactoring object hierarchy that you'll potentially be doing yourself (or those that follow) a disservice in the long run.

[mcv]

Yes, you could do that, but it goes against how everybody has been accessing object properties for the past two decades.

Quite often, you simply want person.address.street.number, and if it doesn't exist, you simply go on without it, and it doesn't matter what the exact reason is why it doesn't exist. This is an extremely common and practical pattern, and it's hindered by layers of null pointer checks.