On 2020-09-12 at 14:07:57 +1000, Cameron Simpson email@example.com wrote:
Dan, I should preface this by saying I don't substantially disagree with you, I just work differently and want to show how and why.
The beauty here is that you have the same pattern of classname.transcribe_value(value) to use whatever binary format you want. And that's a static method because it doesn't need a class or instance for context - it just transcribes the data.
IMO, m.f has less cognitive load than m.X.f, at their definitions and at call sites. Full disclosure: I consider most of Object Oriented Programming to be extraneous cognitive noise.
Whereas I use OOP a lot. Hugely.
Maybe what I needed early on was a good example of a large, well designed OO piece of software to use as a role model. But the large non-OO systems seemed to be much better (in any number of ways, and please don't mistake me for implying that all non-OO systems are good) than the large OO ones. My habits and opinions are certainly shaped from my experience.
Namespaces are one honking great idea. I¹ have modules, you¹ have classes. We¹ build software. Vive la différence! :-)
In other languages (*cough* Java *cough*), there are no functions outside of classes, and static methods fill that role.
Aye. I agree that is an example where static methods exist for language definition reasons instead of functionality. OTOH, the language design is deliberately like that to force encapsulation as a universal approach, which has its own benefits in terms of side effect limitation and code grouping, so there's an ulterior purpose there.
Encapsulation is a good thing, OO or otherwise. Unless, of course, the code is behind an HTTP server and I can't see it from the outside.
¹ in the generic sense of the pronoun