3 ms·

You have to name a wildcard import: import * as bindingName from 'module-url' All exports are also named, so you get an object with all exports as propertie

You have to name a wildcard import: import * as bindingName from 'module-url' All exports are also named, so you get an object with all exports as properties. console.log(bindingName.exportedName) What is so confusing about it? The docs are also pretty clear to me: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#namespace_import https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Maybe you meant bare imports? import 'module-url' In that case it only means: execute the code from that module, I don't care about importing stuff. If they set a global variable or interact with other modules I might use it.

nick238 2y ago
As a Python dev, reading the "import * as bindingName from 'module-url'" seems confusing as it sounds like it'd try to assign multiple things to one name. In Python, the following line pairs are roughly equivalent: import X X = __import__("X") or import X as Y Y = __import__("X") I understand and kinda appreciate the nice (apparent) simplicity of a dedicated "import", especially as you will use it a ton, but I also like the bluntness of Zig where it's not special (well, it has a macro), and you're explicitly doing the assignment: const std = @import("std"); const parseInt = std.fmt.parseInt; Really not a fan of languages that allow importing (using, including...) things where magic happens and a bunch of names are just available without any clear idea where from. Yeah, an IDE will help you find the source of a C function from an #include, but if you're trying to debug some 3rd party library and don't want to download the whole thing, the ability to hand-trace it a bit is just gone. Why mix a bunch of names into the local namespace? If you want short names, just assign it to a single letter variable. Circling back to Python, the only practical place I see 'import * from ...` being used is in libraries where they are bundling up names from a bunch of submodules to be accessible at a top-level. Though, I was searching for an example of this as I know NumPy did it until they undid it: https://github.com/numpy/numpy/pull/24357 https://github.com/numpy/numpy/pull/24357
- augusto-moura 2y ago
  > I understand and kinda appreciate the nice (apparent) simplicity of a dedicated "import", especially as you will use it a ton, but I also like the bluntness of Zig where it's not special (well, it has a macro), and you're explicitly doing the assignment: That is exactly how CommonJS worked for the longest time: const module = require('url') The short end of the stick was the export syntax for CJS, which is basically just assigning a property to an object: module.exports.value = 'foo' The problem solve with the import syntax is that is statically parseable, you just need to parse the top-level of a package to find its dependencies. The explicit export is also a god-send for tooling, which can have a lot of introspection from it, without executing any code.

nick238 2y ago

As a Python dev, reading the "import * as bindingName from 'module-url'" seems confusing as it sounds like it'd try to assign multiple things to one name. In Python, the following line pairs are roughly equivalent: import X X = __import__("X") or import X as Y Y = __import__("X") I understand and kinda appreciate the nice (apparent) simplicity of a dedicated "import", especially as you will use it a ton, but I also like the bluntness of Zig where it's not special (well, it has a macro), and you're explicitly doing the assignment: const std = @import("std"); const parseInt = std.fmt.parseInt; Really not a fan of languages that allow importing (using, including...) things where magic happens and a bunch of names are just available without any clear idea where from. Yeah, an IDE will help you find the source of a C function from an #include, but if you're trying to debug some 3rd party library and don't want to download the whole thing, the ability to hand-trace it a bit is just gone. Why mix a bunch of names into the local namespace? If you want short names, just assign it to a single letter variable. Circling back to Python, the only practical place I see 'import * from ...` being used is in libraries where they are bundling up names from a bunch of submodules to be accessible at a top-level. Though, I was searching for an example of this as I know NumPy did it until they undid it: https://github.com/numpy/numpy/pull/24357 https://github.com/numpy/numpy/pull/24357

augusto-moura 2y ago
> I understand and kinda appreciate the nice (apparent) simplicity of a dedicated "import", especially as you will use it a ton, but I also like the bluntness of Zig where it's not special (well, it has a macro), and you're explicitly doing the assignment: That is exactly how CommonJS worked for the longest time: const module = require('url') The short end of the stick was the export syntax for CJS, which is basically just assigning a property to an object: module.exports.value = 'foo' The problem solve with the import syntax is that is statically parseable, you just need to parse the top-level of a package to find its dependencies. The explicit export is also a god-send for tooling, which can have a lot of introspection from it, without executing any code.