6 ms·
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 wa
by 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 agoWhy do you say that? You may `import * as Foo from “foo”` to create a closed namespace.
- afiori 4y 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 4y 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.