3 ms·

That's true. I guess I misspoke and wasn't as clear as I could be. What I meant to say was: the problem with Python and JavaScript's module system isn't modules

That's true. I guess I misspoke and wasn't as clear as I could be. What I meant to say was: the problem with Python and JavaScript's module system isn't modules themselves, but top-level statements. You are correct that `import` doesn't solve such a problem; It solves the synchronous dependency resolution problem. Realistically, that's just what happens when a language allows top-level statements, as they are executed when a file is loaded. As such, scripting languages tend to fall victim to the problem, but compiled ones don't. I'll update my comment.

rezonant 3y ago
Worth noting that ES-style imports do improve the scenario for cyclic dependencies though, assuming you do not need to reference the symbols imported during the execution of the top level statements. This is because `import { bar } from './bar.js'` makes `bar` a "live binding" -- even if `bar.js` also imports `foo.js` and thus `bar` may initially be undefined due to the cyclic dependency, later when `bar.js` completes its initialization of `bar`, the identifier `bar` in `foo.js` will be updated to match. So if you just need to call that binding within, say, a function or a method call, its typically fine to do so assuming that by the time that function or method call is executed, both modules will have completed their initializations.
- paulddraper 3y ago
  And that is similar to require's behavior for properties on the returned object. const foo = require("foo"); // starts out as empty object exports.bar = function() { return foo.fn(); }
  - rezonant 3y ago
    Yes but the difference is that this: let x = require('foo').x of course, cannot do that. It's a small difference but it does make it easier to fall into the happy path in more cases.
paulddraper 3y ago
> Realistically, that's just what happens when a language allows top-level statements, as they are executed when a file is loaded. As such, scripting languages tend to fall victim to the problem, but compiled ones don't. Lots of languages allow initialization code (e.g. Java static initializer). But in the case of scripting languages, usually the classes and functions themselves are initialization code....i.e. everything is initialization code.

rezonant 3y ago

Worth noting that ES-style imports do improve the scenario for cyclic dependencies though, assuming you do not need to reference the symbols imported during the execution of the top level statements. This is because `import { bar } from './bar.js'` makes `bar` a "live binding" -- even if `bar.js` also imports `foo.js` and thus `bar` may initially be undefined due to the cyclic dependency, later when `bar.js` completes its initialization of `bar`, the identifier `bar` in `foo.js` will be updated to match. So if you just need to call that binding within, say, a function or a method call, its typically fine to do so assuming that by the time that function or method call is executed, both modules will have completed their initializations.

paulddraper 3y ago
And that is similar to require's behavior for properties on the returned object. const foo = require("foo"); // starts out as empty object exports.bar = function() { return foo.fn(); }
- rezonant 3y ago
  Yes but the difference is that this: let x = require('foo').x of course, cannot do that. It's a small difference but it does make it easier to fall into the happy path in more cases.

paulddraper 3y ago

> Realistically, that's just what happens when a language allows top-level statements, as they are executed when a file is loaded. As such, scripting languages tend to fall victim to the problem, but compiled ones don't. Lots of languages allow initialization code (e.g. Java static initializer). But in the case of scripting languages, usually the classes and functions themselves are initialization code....i.e. everything is initialization code.