Re: Make namespace part of runtime
| From: | Mike Schinkel | Date: | Sun, 29 Aug 2021 03:12:24 +0000 |
| Subject: | Re: Make namespace part of runtime | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-115893@lists.php.net to get a copy of this message | ||
> On Aug 28, 2021, at 5:12 PM, Olle Härstedt <olleharstedt@gmail.com> wrote:
>
> 2021-08-27 23:07 GMT+02:00, Rowan Tommins <rowan.collins@gmail.com
> <mailto:rowan.collins@gmail.com>>:
>> 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.
>>
>> 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?
In case you have not seen these, which discuss possibilities but at a higher level than actually how
to implement:
https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/0000-language-evolution.md
<https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/0000-language-evolution.md>
https://phpinternals.news/45 <https://phpinternals.news/45>
-Mike