On 25 July 2019 14:34:07 BST, Nikita Popov <nikita....@gmail.com> wrote: >Based on the received feedback, I plan to change this proposal from >being >"namespace-scoped" to being "directory-scoped" instead. This should >both >resolve some of the concerns and make the proposal more flexible: Not >all >code sharing the same namespace is part of the same package (multiple >packages may have classes in the same namespace)
I think the word "package" here is significant, because all the other variants of this proposal come down to "how can we best emulate package/module support": - the original namespace form assumes that some level of the namespace hierarchy represents a package - the proposal to use a directory assumes that some structure on disk represents a package - Mark's alternative using an explicit include allows every file to say it's part of some package I think it would be better to skip these workarounds, and define a package directly. The differences I see between package and namespace are: 1) Packages should be non-hierarchical. Perhaps most simply a package name could have exactly two parts, like in composer, so it's clear that there is no implied relationship between two packages. 2) A package should be explicitly declared before first use, probably in a separate file. This definition would have scoped declares, and could also have autoload and preload definitions. Or perhaps a package would always be eagerly loaded, allowing us to do more cross-file analysis at compile-time. Obviously, there's a lot to figure out here. Do we define where the package definition lives on disk, or require the user to configure it in some way? Does a package name form the prefix for namespaces within that package, or can a package contain definitions for any namespace? However, I think we should make these design decisions, rather than letting an easy implementation lead us somewhere we'll regret later. I do also share the concern that a proliferation of package options would make the language harder to understand. Part of the motivation for removing short open tags seems to be to make the language more consistent. The ability for a package to configure the compiler as its author intended is certainly better than having to test every combination, but we need to think very carefully about what options we add. Regards, -- Rowan Collins [IMSoP]
