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;"
- 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.
I'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).
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
