> On Aug 27, 2021, at 5:07 PM, Rowan Tommins <rowan.coll...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
