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
What about how exposing internals details makes it hard for library maintainers to evolve things without breaking client code? This is still an issue for dependently typed languages.
2
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
Replying to and
But this is only a problem if the tooling can’t describe the impact of upgrading to the user, right? Version numbers are a very dubious way of conveying that IMO. I’d rather the package manager analysed the changes against my code and told me: nothing should break/this will break
1
3
Yeah, definitely agree on that twitter.com/brendanzab/sta - kind of was working off the assumption of semver (which is what I normally deal with), but yeah, very aware of the limitations on that. Would be cool if we had better control over this without being overwhelming to users.
Quote Tweet
Replying to @brendanzab and @RosaCtrl
But yeah, dependencies are hard - and I do find code evolution super tricky - eg. having a single version number for an entire package, and trying to decide is a behavioral change is breaking or not… ugh.