3 ms·
Remember 20 years ago, when getters and setters were all the rage? Reaching in to access variables was bad, but if you used a getter instead, then that was som
by mrkeen 2y ago
Remember 20 years ago, when getters and setters were all the rage?
Reaching in to access variables was bad, but if you used a getter instead, then that was somehow good because you were doing encapsulation?
IDEs gained the ability to generate your getters and setters for you, C# had properties which streamlined things and made Java look boilerplatey in comparison, and Java got Lombok.
But it was all bullshit. If making fields private is 'locking the door', then adding getters and setters is 'leaving the key on top of the doormat'.
Show me a logic bug caused by a global variable, I'll slap some getters and setters onto it, give it back to you, and it will still have the same logic bug.
What's my point?
It's not that FP has some competing definition of 'global variables' that somehow makes FP look good and imperative look bad, it's that FP actually followed the idea through to its logical conclusion and generalised it as 'shared mutable state', rather than slapping "encapsulation" on it and calling it a day.
> Anyway, nodes are only public if the calling code makes them public by leaking a reference or something.
This is true. However people commonly leak things by putting 'export' in front of them. Otherwise how can callers access them?
- recursive 2y agoI do remember. I never really bought into the dogma about property accessors. Sometimes they are good. But mutable object fields might be fine too. In fact, I even think goto is appropriate in some circumstances. I guess the modern conception of FP says 'all values and state are best modeled immutably'. Whereas I tend to think it's only some of them.