Make namespace part of runtime View as Markdown

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

2021-08-27 23:07 GMT+02:00, Rowan Tommins rowan.collins@gmail.com:

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.

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;"

Yes, I assume this is why Psalm introduced a new annotation
@psalm-internal <namespace>, which does take such a parameter. A PHP
attribute can do this, if it has access to runtime namespace.

• 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.

What's the estimated effort for adding package support to PHP? Did
anyone outline a possible implementation?

Olle