4 ms·
> 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 wha
by n2d4 3y 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 3y agoWhat's the alternative then? Maintaining a fork? It's the same update problems just with more hassle.
- Nullabillity 3y agoYes, 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 3y 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 3y agoYes, accessing the internal parts is taking on the burden. Forking is acknowledging that you have done so.
- realusername 3y agoSo 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 3y agoI 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 3y 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 3y agoWhy do you say that? You may `import * as Foo from “foo”` to create a closed namespace.
- afiori 3y agoBecause 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 3y agoSingleton 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.