4 ms·

I can't recall a single time in JS/TS, C# or even Java where I went "phew, glad i made that private!". In TS, i default to protected for internal implementatio

by jschrf 3y ago

I can't recall a single time in JS/TS, C# or even Java where I went "phew, glad i made that private!". In TS, i default to protected for internal implementation details. Why would one hinder future extenders by default?

thfuran 3y ago
Unless you're going 100% immutable everything (which the language isn't great for), advocating for making all members public in java seems roughly as sane as advocating for declaring all variables and returns as Object.
oweiler 3y ago
Because extensibility should be a design decision.
- chii 3y ago
  extensibility not thought of during design is a flaw. which can be patched over if the actual internals are reachable.
  - everforward 3y ago
    Sure, but extensibility often comes with complexity. If I'm making something non-extensible it's to keep things simple or to prevent a bunch of bugs around people trying to extend something with complicated state. They always have the nuclear option of forking and making those fields no longer internal. They'll have to take on the maintenance overhead that I shirked, but that should be fine if they need it that badly.
    - kriz9 3y ago
      I agree. Most of my frustration comes from unescessary abstractions and not code that I can't extend.
    - chii 3y ago
      > They always have the nuclear option of forking and making those fields no longer internal. while that is always possible, it is not always reasonable. If you take firefox as the example, the removal of the XUL extension api is one such. And while there's many a forks to keep the old XUL api, none of them really caught on, and so support for them such as maintaining security patches etc fails.
- mst 3y ago
  That feels like an argument for 'final' more than 'private.' Personally, at least for library code, I tend to assume -somebody- will extend any given class of mine at -some- point and would prefer they had a reasonable time doing so, but I use 'prefer' advisedly since there are absolutely situations where doing so would almost certainly be a footgun and in that case I'd rather dissuade the user before sinking time into the idea.
SigmundA 3y ago
If I am understanding the issue here I don't believe C# would suffer from this issue since reflection works not only on public method access where those methods use privates internally but in fact could access privates directly. In C# private is more of suggestion than an enforced concept since you can do anything you want with reflection, which is very useful and necessary sometimes. Keeps normal code clean and encapsulated while allowing one to go under the covers as needed. Seems very strange that not only can you not get to private members directly in JS but even worse you can't call a public method that use a private though a proxy, bizarre and against what I would think JS to be.
HWR_14 3y ago
Because making things public or protected hinders future maintainers by default.
UncleMeat 3y ago
I've got hundreds in the codebase I manage. Imagine you have a type that represents some domain state. It has a bunch of fields that are used to represent this state. But that state has invariants. There are certain combinations of values that the fields are not allowed to take and they relate to each other in complex ways. A well designed interface to this type is such that every sequence of methods called on one of these objects will maintain the invariants. If you instead just directly expose the fields then absolutely nothing guarantees that the invariants hold. Yes, if the first thing you do when you create a private field is write a public getter and a public setter then you haven't gained anything. But the power is in not writing these methods.

by jschrf 3y ago

thfuran 3y ago

Unless you're going 100% immutable everything (which the language isn't great for), advocating for making all members public in java seems roughly as sane as advocating for declaring all variables and returns as Object.

oweiler 3y ago

Because extensibility should be a design decision.

chii 3y ago
extensibility not thought of during design is a flaw. which can be patched over if the actual internals are reachable.
- everforward 3y ago
  Sure, but extensibility often comes with complexity. If I'm making something non-extensible it's to keep things simple or to prevent a bunch of bugs around people trying to extend something with complicated state. They always have the nuclear option of forking and making those fields no longer internal. They'll have to take on the maintenance overhead that I shirked, but that should be fine if they need it that badly.
  - kriz9 3y ago
    I agree. Most of my frustration comes from unescessary abstractions and not code that I can't extend.
  - chii 3y ago
    > They always have the nuclear option of forking and making those fields no longer internal. while that is always possible, it is not always reasonable. If you take firefox as the example, the removal of the XUL extension api is one such. And while there's many a forks to keep the old XUL api, none of them really caught on, and so support for them such as maintaining security patches etc fails.
mst 3y ago
That feels like an argument for 'final' more than 'private.' Personally, at least for library code, I tend to assume -somebody- will extend any given class of mine at -some- point and would prefer they had a reasonable time doing so, but I use 'prefer' advisedly since there are absolutely situations where doing so would almost certainly be a footgun and in that case I'd rather dissuade the user before sinking time into the idea.

SigmundA 3y ago

If I am understanding the issue here I don't believe C# would suffer from this issue since reflection works not only on public method access where those methods use privates internally but in fact could access privates directly. In C# private is more of suggestion than an enforced concept since you can do anything you want with reflection, which is very useful and necessary sometimes. Keeps normal code clean and encapsulated while allowing one to go under the covers as needed. Seems very strange that not only can you not get to private members directly in JS but even worse you can't call a public method that use a private though a proxy, bizarre and against what I would think JS to be.

HWR_14 3y ago

Because making things public or protected hinders future maintainers by default.

UncleMeat 3y ago

I've got hundreds in the codebase I manage. Imagine you have a type that represents some domain state. It has a bunch of fields that are used to represent this state. But that state has invariants. There are certain combinations of values that the fields are not allowed to take and they relate to each other in complex ways. A well designed interface to this type is such that every sequence of methods called on one of these objects will maintain the invariants. If you instead just directly expose the fields then absolutely nothing guarantees that the invariants hold. Yes, if the first thing you do when you create a private field is write a public getter and a public setter then you haven't gained anything. But the power is in not writing these methods.