Because he judges a series of dots by themselves, not because any law mandantes anything. He gives a shit about these grandiose names, show me the code and let's discus on that.
If you present a code with ten dots, he will probably say it is bad code. But he won't invoke law of demeter. That's the point I think.
Is like invoking SRP. Fuck that. When you are experienced, you develop a sense on delineating responsabilities in a way that fits your application.
I am not David of course, but I have participated in some discussions with him, and we think very much alike on these topics, I think what I say above is right.
Going to switch to myself now: When people invoke SRP a priori they sometimes end up with one class == one method in a theoretical a priori way.
I don't think that works. It goes in the reverse direction. SRP is inferred, it emerges, it is not applied as if it was a logical proposition.
> And this gets to the crux of the Single Responsibility Principle. This principle is about people.
> When you write a software module, you want to make sure that when changes are requested, those changes can only originate from a single person, or rather, a single tightly coupled group of people representing a single narrowly defined business function. You want to isolate your modules from the complexities of the organization as a whole, and design your systems such that each module is responsible (responds to) the needs of just that one business function.