5 ms·

Private is a terrible concept. Only two days ago I chose to rewrite a chunk of code simply because I couldn’t call a private function that did precisely what I

Private is a terrible concept. Only two days ago I chose to rewrite a chunk of code simply because I couldn’t call a private function that did precisely what I needed. Also “considered harmful” is an overused cliche I wish people would stop saying it.

n2d4 4y ago
> Only two days ago I chose to rewrite a chunk of code simply because I couldn’t call a private function that did precisely what I needed. It may have done what you needed in the current version of your library, but just look at it from the perspective of the library author. If they ever want to refactor, or maybe remove, that private function, it would break a lot of people's code. And even if it were marked private or deprecated, it would still break a lot of people's code. You could say "but if your code gets broken it's your own fault" and yes you're right, but it wouldn't stop those people from loudly complaining to the author.
- realusername 4y ago
  What's the alternative then? Maintaining a fork? It's the same update problems just with more hassle.
  - Nullabillity 4y ago
    Yes, maintaining a fork means that you're explicitly taking on the maintenance burden from that point on, and are on your own in terms of updates. That's a reasonable commitment to ask for if you're poking around in implementation details.
    - ricardobeat 4y ago
      > you're explicitly taking on the maintenance burden How are you not taking the burden of maintenance when writing code that uses private-by-convention properties? The difference seems pretty abstract, a fork will require the same rework when internal properties change.
      - Nullabillity 4y ago
        Yes, accessing the internal parts is taking on the burden. Forking is acknowledging that you have done so.
    - realusername 4y ago
      So basically it's the same result (you need to manage updates yourself and test your changes) except that your modifications are now scattered around dozen of repositories instead of one, and what's the benefit of this added complexity compared to a patch? None that I can see?
- hajile 4y ago
  I think it’s commonly understood in the JS community: If you modify a library property with an underscore, you are on your own. Adding a broken feature that was widely criticized for years (more than any other JS feature before it was added — including type coercion) just so some maintainers don’t have to tell users no about one particular thing isn’t a great idea. It’s even less of a great idea when you consider that modules exist. Add a variable without marking it for export and you’re good to go.
  - afiori 4y ago
    > It’s even less of a great idea when you consider that modules exist. Add a variable without marking it for export and you’re good to go. Javascript modules do not work particularly well as namespaces.
    - hajile 4y ago
      Why do you say that? You may `import * as Foo from “foo”` to create a closed namespace.
      - afiori 4y ago
        Because all the import * as Foo from "foo" produce the same singleton with shared state. What I would like is something like function(param1, param2){ return module Name { import {param1} from super; export let A = param1 + 1; // This line would cause an error as // param2 is not imported from the enclosing scope // export let AA = param2 + 2; } }
        hajile 4y ago
        Singleton is orthogonal to namespaces. One is about data creation and the other about naming stuff. If I want to create new pieces of data, I have to make an allocation with a constructor. Reusing methods provided by modules is effectively the same as classes (the two being mathematically equivalent, but closures not having all the footguns). This is true no matter if your code is OOP, imperative, or functional.
deepsun 4y ago
> I couldn’t call a private function that did precisely what I needed. Well, in a neighboring comment someone is suggesting making the private stuff local, so it cannot be called as well. So your problem would persist just as well.
pjmlp 4y ago
It is a great concept, the only way to force developers that feel entitled to reach out to implementation details and then go cry on social media when their beloved app breaks, to actually follow what is available to them.
jabradoodle 4y ago
Over time people will become dependant on your entire api, bugs and all. Without private methods or some equivalent you won't be able to change your library without breaking lots of people's code. It also makes understanding the interface hard, if everything is public, how do I know which methods are intended for me to consume, and which are internal helpers. Of course, not all interfaces will suit your need and some are poorly designed.
- hajile 4y ago
  If they begin with an underscore, they are internal. This has been convention for decades now.
  - jabradoodle 4y ago
    That is fair and a trade off. That doesn't make the concept of private functions a bad one.
    - hajile 4y ago
      Modules already offer private variants and methods. The only real difference is less boilerplate, more customization, no confusing edge cases, and not allowing the inheritance footgun.

n2d4 4y ago

> Only two days ago I chose to rewrite a chunk of code simply because I couldn’t call a private function that did precisely what I needed. It may have done what you needed in the current version of your library, but just look at it from the perspective of the library author. If they ever want to refactor, or maybe remove, that private function, it would break a lot of people's code. And even if it were marked private or deprecated, it would still break a lot of people's code. You could say "but if your code gets broken it's your own fault" and yes you're right, but it wouldn't stop those people from loudly complaining to the author.

realusername 4y ago
What's the alternative then? Maintaining a fork? It's the same update problems just with more hassle.
- Nullabillity 4y ago
  Yes, maintaining a fork means that you're explicitly taking on the maintenance burden from that point on, and are on your own in terms of updates. That's a reasonable commitment to ask for if you're poking around in implementation details.
  - ricardobeat 4y ago
    > you're explicitly taking on the maintenance burden How are you not taking the burden of maintenance when writing code that uses private-by-convention properties? The difference seems pretty abstract, a fork will require the same rework when internal properties change.
    - Nullabillity 4y ago
      Yes, accessing the internal parts is taking on the burden. Forking is acknowledging that you have done so.
  - realusername 4y ago
    So basically it's the same result (you need to manage updates yourself and test your changes) except that your modifications are now scattered around dozen of repositories instead of one, and what's the benefit of this added complexity compared to a patch? None that I can see?
hajile 4y ago
I think it’s commonly understood in the JS community: If you modify a library property with an underscore, you are on your own. Adding a broken feature that was widely criticized for years (more than any other JS feature before it was added — including type coercion) just so some maintainers don’t have to tell users no about one particular thing isn’t a great idea. It’s even less of a great idea when you consider that modules exist. Add a variable without marking it for export and you’re good to go.
- afiori 4y ago
  > It’s even less of a great idea when you consider that modules exist. Add a variable without marking it for export and you’re good to go. Javascript modules do not work particularly well as namespaces.
  - hajile 4y ago
    Why do you say that? You may `import * as Foo from “foo”` to create a closed namespace.
    - afiori 4y ago
      Because all the import * as Foo from "foo" produce the same singleton with shared state. What I would like is something like function(param1, param2){ return module Name { import {param1} from super; export let A = param1 + 1; // This line would cause an error as // param2 is not imported from the enclosing scope // export let AA = param2 + 2; } }
      - hajile 4y ago
        Singleton is orthogonal to namespaces. One is about data creation and the other about naming stuff. If I want to create new pieces of data, I have to make an allocation with a constructor. Reusing methods provided by modules is effectively the same as classes (the two being mathematically equivalent, but closures not having all the footguns). This is true no matter if your code is OOP, imperative, or functional.

deepsun 4y ago

> I couldn’t call a private function that did precisely what I needed. Well, in a neighboring comment someone is suggesting making the private stuff local, so it cannot be called as well. So your problem would persist just as well.

pjmlp 4y ago

It is a great concept, the only way to force developers that feel entitled to reach out to implementation details and then go cry on social media when their beloved app breaks, to actually follow what is available to them.

jabradoodle 4y ago

Over time people will become dependant on your entire api, bugs and all. Without private methods or some equivalent you won't be able to change your library without breaking lots of people's code. It also makes understanding the interface hard, if everything is public, how do I know which methods are intended for me to consume, and which are internal helpers. Of course, not all interfaces will suit your need and some are poorly designed.

hajile 4y ago
If they begin with an underscore, they are internal. This has been convention for decades now.
- jabradoodle 4y ago
  That is fair and a trade off. That doesn't make the concept of private functions a bad one.
  - hajile 4y ago
    Modules already offer private variants and methods. The only real difference is less boilerplate, more customization, no confusing edge cases, and not allowing the inheritance footgun.