On Tue, 30 Jul 2019 at 15:08, Nikita Popov <nikita....@gmail.com> wrote:
> 5. Introduce a first-class module/package concept and support per-package > declares. This is arguably the closest fit for what is needed, but also the > most complex solution. This is a fairly big problem space and I personally > do not want to pursue this outside a certain narrow scope. > > In particular I have serious doubts about retrofitting (at this point in > time) an invasive module system that involves explicit export and import > management, along the lines of what Michal is describing. (Though I will be > happily surprised if someone comes forward with a proposal to do this in a > non-invasive way.) > > What I think might be worth pursuing though, is a much weaker package > notion that essentially grants some language-integration to the existing > notion of composer packages. Instead of having a declare_directory() we'd > have declare_package(), which is bound to a certain path and can be used to > specify declares, but also used for other purposes, such as package-private > visibility. > > If I may make another Rust analogy, this would be more like Rust crates > than Rust modules. The analogy being that this is a more coarse grained > level, and is fairly tightly integrated with the package manager (but of > course still usable without it). > Yes, I was thinking of something more like Composer packages, rather than like JS modules: code would mostly work as presently, but with some notion of being "owned" by a particular package. This doesn't mean all the functions of Composer would be integrated, but could provide richer primitives, such as registering an autoload callback or preload list to a particular package, rather than having to perform string matches. Regards, -- Rowan Collins [IMSoP]
