4 ms·

How is this not a problem in node.js? Keep in mind, I don't know node. However, in general, there's going to be several common problems in any language: Valu

by NateDad 12y ago

How is this not a problem in node.js? Keep in mind, I don't know node. However, in general, there's going to be several common problems in any language: Values from v1 and v1.1 won't interoperate perfectly. If you get a v1 object and pass it to B which uses v1.1 to operate on it, stuff may blow up / not work correctly, which may only be obvious in rare runtime situations. Any external resources used by both v1 and v1.1 will now be in contention. If both of them try to open port 12345, or write to the same config file, for example. And that assumes that there's no ambiguity based on just importing almost the same code twice, like if you say C.Foo... which C? Can be gotten around by always namespacing the code via the version number, I suppose. There's no magic fix for these problems. Some human has to go through all the dependencies and make sure that there won't be conflicts. Maybe v1 and v1.1 can coincide just fine, maybe they'll instantly explode. Computers can't figure that stuff out.

espadrine 12y ago
> How is this not a problem in node.js? Keep in mind, I don't know node. The automated tool npm relies on a local nested tree. The A -> C-v1 and A -> B -> C-v1.1 problem would look like this: (your code) node_modules/ A/ (code for A) node_modules/ C/ (code for C at v1) B/ (code for B) node_modules/ C/ (code for C at v1.1) The whole tree is created painlessly when you enter `npm install A`. The program figures out the dependencies through JSON files bundled with each module. They include version requirements; npm simply chooses the highest version that respects those requirements. Within each directory, `require('C')` looks for `./node_modules/C/` and finds the module it actually needs. All versions of all modules are kept at all times on a central public server at http://npmjs.org/ http://npmjs.org/. This design is only possible in some languages. Dart, for instance, cannot apply that to its libraries because its types are globally defined and would therefore clash. In Go, types are not global, which means this design can apply in principle, according to the Go Spec. However, the implemented import syntax does not act in a way that would make this possible. Oddly enough, that syntax is not specified in the Go Spec: > The interpretation of the ImportPath is implementation-dependent but it is typically a substring of the full file name of the compiled package and may be relative to a repository of installed packages.
- NateDad 12y ago
  Getting the modules and making the tree is easy. Making the code work is hard. Yes, sometimes this will work... but if A passes an object from v1 into B and B passes that object into v1.1... that can blow up. If v1 and v1.1 both use any global resources, that can blow up. It doesn't sound like node addresses those problems at all, which are the only ones that are actually difficult.

by NateDad 12y ago

espadrine 12y ago

> How is this not a problem in node.js? Keep in mind, I don't know node. The automated tool npm relies on a local nested tree. The A -> C-v1 and A -> B -> C-v1.1 problem would look like this: (your code) node_modules/ A/ (code for A) node_modules/ C/ (code for C at v1) B/ (code for B) node_modules/ C/ (code for C at v1.1) The whole tree is created painlessly when you enter `npm install A`. The program figures out the dependencies through JSON files bundled with each module. They include version requirements; npm simply chooses the highest version that respects those requirements. Within each directory, `require('C')` looks for `./node_modules/C/` and finds the module it actually needs. All versions of all modules are kept at all times on a central public server at http://npmjs.org/ http://npmjs.org/. This design is only possible in some languages. Dart, for instance, cannot apply that to its libraries because its types are globally defined and would therefore clash. In Go, types are not global, which means this design can apply in principle, according to the Go Spec. However, the implemented import syntax does not act in a way that would make this possible. Oddly enough, that syntax is not specified in the Go Spec: > The interpretation of the ImportPath is implementation-dependent but it is typically a substring of the full file name of the compiled package and may be relative to a repository of installed packages.

NateDad 12y ago
Getting the modules and making the tree is easy. Making the code work is hard. Yes, sometimes this will work... but if A passes an object from v1 into B and B passes that object into v1.1... that can blow up. If v1 and v1.1 both use any global resources, that can blow up. It doesn't sound like node addresses those problems at all, which are the only ones that are actually difficult.