On Sunday, December 28, 2014 1:34:50 PM UTC-5, Mauro wrote: > > > Now the popular packages tend use include in a way that's fairly > > harmless--i.e. to allow a lot of different symbols and functions to be > > exported from a single module, without writing all the code in a single > > giant file. But given that the good uses of include are pretty > restricted, > > I think we'd be better off if the default tool for doing this kind of > thing > > was more restrictive. > > Any thoughts on how a restricted include should work? >
Sure: we already have modules. The good thing about them is that top level code only runs once, and it executes in a separate scope from the code where the module is imported. Modules are great, and you should use one any time you want to run code that is in one file from another file. I can only speculate about the reason that people still use include, even though Julia has nice modules. There's a bit about "mixins" in the manual (http://julia.readthedocs.org/en/latest/manual/modules/#modules-and-files), but I haven't ever seen include used that way in the wild. The common case appears to be that people sometimes want symbols in a "child file" to show up in a "parent module". If you make the child file into a module, export some of its symbols, and then say "importall Child" in the parent module, you get the exported symbols of the child as non-exported symbols of the parent. But so far there isn't an easy way to 1) make all of the non-exported symbols of a child module into non-exported symbols of a parent module, nor 2) "reexport" all of the exported symbols of a child module from a parent module. 1) feels kind of suspect to me because I think it's better to be explicit about these things. But I'd rather see this behavior enabled if it would convince people to stop using include, which is much worse. I'm not sure about names, but 1) could be something like importunexported Child which would be like using except that it would load all the symbols in Child, not just the ones that were explicitly exported. Even though this is not perfectly explicit, it maintains the advantages that the top level code in Child is known to run only once, and that it runs in a separate scope from Parent so that symbols already in Parent can't affect the behavior of top level code in Child. 2) could be something like reexport Child
