4 ms·

There is a cost to everything-private, which is that downstream consumers of your software hate you because now they have to get PRs merged for every little thi

There is a cost to everything-private, which is that downstream consumers of your software hate you because now they have to get PRs merged for every little thing that you didn't anticipate. Actually it probably makes the problem worse because we're just going to patch your shit and access the private fields anyway. The functional programming and especially the data driven schools of thought tackle the same problem more elegantly.

wereHamster 8y ago
> downstream consumers of your software hate you because now they have to get PRs merged for every little thing that you didn't anticipate If that's the case then the build system or dependency management tool is too stupid. NPM is, for example, because you can't install most dependencies straight from git repositories. Most npm packages need to be built on the developers machine and only artefacts are uploaded to the npm registry. If you need to patch for example babel (which you depend on through five levels of intermediate dependencies), you're in for a hell. Haskell, on the other hand, makes it very easy to fork & patch a dependency (even a transient one) and you can use that while upstream figures out how to merge a PR.
- kbenson 8y ago
  The ability to quickly use your PR for a system that was overly private is beneficial, but is still decidedly non-zero in terms of time and effort. The PR has to be written in the first place, for example. And that's before we get into whether upstream even accepts your patch without modifications, or even accepts it at all.
  - dustingetz 8y ago
    he means we can fork and vendor locally but it doesn’t scale when doing enterprise java for many reasons
    - wereHamster 8y ago
      I'm always assuming that upstream will either accept the PR, or explain how to achieve my goal without requiring a change to upstream. Either way, such a pull request should be resolved fairly quickly and not linger around for too long. Why does this not not scale when doing enterprise java? Is it the 'enterprise', or 'java', or the combination thereof?
      - dustingetz 8y ago
        Many reasons, cultural, not often on github or developed openly, huge variance in quality, maybe not so agile, huge code drops every 6 months with tons of churn so even tiny patches can add huge overhead to the rebase when you upgrade versions soooo you don't.
zackmorris 8y ago
I agree, also little or no thought has been given to readonly fields in OOP. I view objects as a natural outcome of mutability, so in that sense they are a code smell. I've found that using const liberally (and keeping methods free of side effects) significantly reduces the number of variables in each object. Which means that I can make more of those const variables public, which tends towards better reusability/composability.

wereHamster 8y ago

> downstream consumers of your software hate you because now they have to get PRs merged for every little thing that you didn't anticipate If that's the case then the build system or dependency management tool is too stupid. NPM is, for example, because you can't install most dependencies straight from git repositories. Most npm packages need to be built on the developers machine and only artefacts are uploaded to the npm registry. If you need to patch for example babel (which you depend on through five levels of intermediate dependencies), you're in for a hell. Haskell, on the other hand, makes it very easy to fork & patch a dependency (even a transient one) and you can use that while upstream figures out how to merge a PR.

kbenson 8y ago
The ability to quickly use your PR for a system that was overly private is beneficial, but is still decidedly non-zero in terms of time and effort. The PR has to be written in the first place, for example. And that's before we get into whether upstream even accepts your patch without modifications, or even accepts it at all.
- dustingetz 8y ago
  he means we can fork and vendor locally but it doesn’t scale when doing enterprise java for many reasons
  - wereHamster 8y ago
    I'm always assuming that upstream will either accept the PR, or explain how to achieve my goal without requiring a change to upstream. Either way, such a pull request should be resolved fairly quickly and not linger around for too long. Why does this not not scale when doing enterprise java? Is it the 'enterprise', or 'java', or the combination thereof?
    - dustingetz 8y ago
      Many reasons, cultural, not often on github or developed openly, huge variance in quality, maybe not so agile, huge code drops every 6 months with tons of churn so even tiny patches can add huge overhead to the rebase when you upgrade versions soooo you don't.

zackmorris 8y ago

I agree, also little or no thought has been given to readonly fields in OOP. I view objects as a natural outcome of mutability, so in that sense they are a code smell. I've found that using const liberally (and keeping methods free of side effects) significantly reduces the number of variables in each object. Which means that I can make more of those const variables public, which tends towards better reusability/composability.