Re: Make namespace part of runtime

> On Aug 27, 2021, at 5:07 PM, Rowan Tommins <rowan.collins@gmail.com> wrote: > > On 27/08/2021 20:47, Olle Härstedt wrote: >> As a followup for my previous post, I think this could be a good place >> to start to enable attribute writers to create encapsulation mechanics >> for composition, like namespace visibility, "internal" access or >> friend classes. > > > In my experience PHP projects tend to use namespace hierarchies which are deep rather than > broad, and I'm not sure how easily those hierarchies could be re-purposed as scopes. > > Clicking through the Symfony source at random for an example, I found "namespace > Symfony\Component\Messenger\Transport\Serialization\Normalizer", which contains only one class. I have noticed the same, including in some of my earlier PHP code soon after namespaces became available. I often wonder if those implement deep namespaces did so because "it seemed like a good idea at the time?" I have since worked hard to minimize depth of any PHP namespace hierarchy I have worked with, and as a happy coincidence it reduces the complexity of the code in the projects that use those libraries. #fwiw > A trivial implementation of namespace visibility which just matched the exact namespace string > would be completely useless for that class (it would be the same as "private"). A slightly > less trivial implementationmight allow access from "child namespaces", but that > wouldn't help in this case. > > However, it might be really useful to restrict usage of that class, or some of its members, to > classes in the "Symfony\Component\Messenger" namespace; or maybe to those in the > "Symfony\Component\Messenger\Transport\Serialization" namespace. > > I can see two ways of enabling that: > > - Allowing visibility modifiers to specify exactly what level of prefix they refer to. This is > apparently how Scala approaches things, allowing you to write the equivalent of > "private[Symfony\Component\Messenger] $foo; > protected[Symfony\Component\Messenger\Transport\Serialization] $bar;" +1 > - Introducing a separate concept of "package", either orthogonal to namespaces or > overlapping with them, e.g. "package Symfony\Component\Messenger; namespace > Transport\Serialization\Normalizer;" would still give a class name beginning > "Symfony\Component\Messenger\Transport\Serialization\Normalizer", but would define > "internal" to mean accessible within the "Symfony\Component\Messenger" package. +100 > 'm personally quite keen on the idea of packages, because they're how a lot of PHP > code is developed in practice - as modular libraries linked by Composer - and I think we could > optimise the language for that use (e.g. applying more cross-file optimisations within a fully > preloaded package). Yes, agree. -Mike