Conversation

My take on encapsulation
Quote Tweet
Replying to @ProgrammerDude and @puffnfresh
No, type systems that don't let us express constraints in full fidelity are bad, but we work with what we've got. Encapsulation is a necessary evil until types precisely specify what is and isn't possible.
3
This Tweet was deleted by the Tweet author. Learn more
The summary seems to be that the original author of something chooses arbitrarily what to encapsulate, but the encapsulated parts may be useful for the user. The other reason is that the safety provided by encapsulation is not that valuable if you have static typing
1
I disagree, I think encapsulation is more about design and intention, but that's why I also believe if we get refined or dependent types there's less need for encapsulation
1
Replying to and
I think cooperative development still requires one to violate assumptions library developers made in order to adapt the library to the unique application context. Which is fine. The problem is that upgrades require people to read code to figure out that this is now a problem.
1
2
And in that sense dependent types help if you accept the pain of proving all your exposed interfaces. But this is neither very realistic nor very practical (as problems can quickly cascade out of control). Something in between with static/dynamic analysis may be a way forward?
1
Show replies
Replying to
Yes, but the argument I have seen there is that you can easily refactor the client code to adapt to the changes made in a dependency that didn't use encapsulation. I'm not sure if I agree though
2
It might be that people just want more control over adaptation from the application level; and this isn’t at odds with encapsulation and security at all. I know has talked about this in Twitter threads before, but unsure if blogged about it.
1
Show replies