Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127517
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\))
Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2
In-Reply-To: <7840468C-F60C-4A44-AE40-16F9007EF428@rwec.co.uk>
Date: Sat, 31 May 2025 14:02:43 +0200
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <160E9B1D-9AF6-479B-A628-A73C618D7C1B@garsi.de>
References: <CADK1yXKg1xpneLs3vJ=nUAAGaVuBhqkEMgbBVaYfcBfQL2vkDg@mail.gmail.com>
 <CAEUnE0dxRwjhKC64XHWkF3bNRLgjkgSJ9oMajRPfwLoDWy3x-g@mail.gmail.com>
 <78641D8B-AF1D-4912-920A-D75A37C32F05@rwec.co.uk>
 <CAEUnE0dVyQ9NQonEBU6wkKM+WsyLXt68jAGYjsz270w_Fa8=Fw@mail.gmail.com>
 <CF275E74-F6AE-4357-8586-2FF17DC84FB5@rwec.co.uk>
 <CAEUnE0eR-0c=pDxgFrB4n60rGescZDVzOgb4uJbYK1aLvQE8=A@mail.gmail.com>
 <354cb888-97c4-4f8c-a0da-359d1e63c0f9@rwec.co.uk>
 <CAEUnE0dffEmFHV872btX5x_mbwmRmY1GCw+OPPrtr6sLD+u_zg@mail.gmail.com>
 <10D95B6E-094B-4EAE-A18A-AF6B795CB352@rwec.co.uk>
 <2adbff61-5e11-4d39-ab5c-d7950a4550a6@app.fastmail.com>
 <79E7FA26-2F5A-470C-B1DF-12CC46A08FE5@rwec.co.uk>
 <cda01760-9f0e-48e4-801d-f436243e088c@app.fastmail.com>
 <1c6dcd84-9016-48e1-971f-de7749cbdce8@rwec.co.uk>
 <D01184DD-EA70-41A4-9306-E09F904042C5@garsi.de>
 <a98a83fd-5486-4713-984b-d4fdb111d85d@app.fastmail.com>
 <44F59416-3922-4AF4-881A-C64F2C4E9345@rwec.co.uk>
 <7F11844A-A98C-4843-BC94-815FBCD2B73F@garsi.de>
 <7840468C-F60C-4A44-AE40-16F9007EF428@rwec.co.uk>
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
From: alwin@garsi.de (Alwin Garside)

On 30 May 2025, at 21:29, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> =
wrote:
>=20
> On 30 May 2025 19:21:08 BST, Alwin Garside <alwin@garsi.de> wrote:
>> In the example above, I image calling or extending the `Foo::bar()` =
method from somewhere outside the `Acme` namespace would trigger an =
E_USER_WARNING or E_USER_NOTICE. The warning/notice could then be =
suppressed when explicitly overriding an `#[\Internal]` method with =
`#[\Override]`.
>=20
>=20
> I don't see any reason for the message to be any quieter or easier to =
override than calling a private method.

If there were a dedicated `internal` modifier keyword, sure. However if =
one simply wants to advertise clearly to other developers that they =
should expect the code to break anytime using an attribute, I feel a =
compile-time critical error is a bit too strict.

>=20
> Indeed, one use of an internal/module-private feature would be when =
the author wants to split up a class that has a large number of private =
methods: the new classes need to be able to talk to each other, so the =
existing "private" keyword is no longer appropriate, but the intended =
surface to users of the library has not changed. The user is making =
exactly the same decision by ignoring the "internal" flag as they are if =
they use reflection or code-rewriting to ignore/remove the "private" =
flag.

I understand your point, but playing devil's advocate for a minute here: =
I'd argue that if a class reaches the point where it has too many =
private methods, something has clearly gone wrong in the architecture or =
abstraction of that class. It probably means part of the functionality =
needs to be hoisted out to a separate class with its own self-contained, =
stable interface.

One could also argue that if the author really wishes to break private =
methods up across multiple classes, they could also use reflection (or =
preferably: a method call wrapped in a closure bound to the target =
class) to access their own private methods.

My experience with module-level visibility out in the wild (mostly in =
Java), has mostly been libraries where the authors apparently couldn't =
be bothered to dedicate to a stable interface for more specific =
implementations of certain template-pattern adapters and the like =E2=80=93=
 the Android source code is full of this.

[rant]
I specifically remember dealing with a DB adapter interface and =
accompanying abstract class, along with implementations for several =
DBMSs. There was an implementation for the specific DBMS I wanted to =
use, however, per the interface, it was completely tied into a separate =
pagination construction which led to a leaky abstraction, and was badly =
optimized for my use case. I just needed to override one or two methods =
to make it work for me, but the platform visibility on those methods =
meant I had to copy-paste both the abstract class and the adapter class =
to fix the functionality, giving me more code to maintain in the =
process.
I think this is a good example where package/module-level visibility =
makes developers complacent, and not care about offering a library that =
is easy to extend or encapsulate.
[/rant]

Alwin=