Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115888
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <6074db02-5540-1831-e77d-0ed8f882a63e@gmail.com>
Date: Fri, 27 Aug 2021 20:02:18 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <922FCDA0-F83C-4374-A1E8-76D59ADD6338@newclarity.net>
References: <CAJpLVh0i0mv=v7uGOAry4S3DAbYzJBhVyo-ziuki_Tdi-r+g9g@mail.gmail.com>
 <6074db02-5540-1831-e77d-0ed8f882a63e@gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] Make namespace part of runtime
From: mike@newclarity.net (Mike Schinkel)

> On Aug 27, 2021, at 5:07 PM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> On 27/08/2021 20:47, Olle H=C3=A4rstedt 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.
>=20
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> I can see two ways of enabling that:
>=20
> - 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=20

> - 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=