Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127525
Feedback-ID: id5114917:Fastmail
Message-ID: <2c5c241c-bd05-4200-b6ee-e94c8ab0db1b@rwec.co.uk>
Date: Sun, 1 Jun 2025 23:01:16 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2
Content-Language: en-GB
To: internals@lists.php.net
References: <CADK1yXKg1xpneLs3vJ=nUAAGaVuBhqkEMgbBVaYfcBfQL2vkDg@mail.gmail.com>
 <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>
 <160E9B1D-9AF6-479B-A628-A73C618D7C1B@garsi.de>
 <CAEUnE0eYuvQWMJ6cffhyT-=A-Tj4WiknfALE0jfV=OHoqKMSsw@mail.gmail.com>
 <cb08e628-72ad-4ad9-8ead-bcb0cbcbfbd1@app.fastmail.com>
In-Reply-To: <cb08e628-72ad-4ad9-8ead-bcb0cbcbfbd1@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 01/06/2025 17:05, Larry Garfield wrote:
> I think there's a key assumption here still that is at the root of much of the disagreement in this thread.
>
> Given that code from multiple files is clustered together into a "thing"
> and Given we can use that "thing" to define a boundary for:
> * name resolution (what Michael is after);
> * visibility (what I am after);
> * more efficient optimizations (what Arnaud showed is possible);
> * various other things
> Then the key question is: Who defines that boundary?
>
> Is it the code*author* that defines that boundary?  Or is it the code*consumer*?
>
> Similarly, is it the code author or consumer that has to Do Work(tm) in order to leverage the desired capability?  Or both?


My take on this is that both need to exist as *separate* features.

The author should define the boundary for things like visibility and 
optimisation. It should be possible to take an existing Composer 
package, add some metadata to it in some way, and have the engine make 
some useful assumptions. The consumer of that package should not need to 
care about the difference, except in edge cases like trying to define 
additional classes with the same prefix as a third-party package.

On the other hand, the consumer should define the boundary for isolating 
name resolution. It should be possible to take any folder of PHP files, 
with no metadata about package management, and load it in a context 
where duplicate class names are allowed. The author of the package 
shouldn't need to make any changes, except in edge cases like highly 
dynamic code which needs additional hints to work correctly when sandboxed.

The first feature is an add-on to the extremely successful ecosystem 
based on the assumption that packages will inter-operate based on agreed 
names. The second feature is a bridge between that ecosystem and the 
very different world of plugin-based web applications, which want to 
manage multiple pieces of code which are not designed to co-operate, and 
run them side by side.

JS has come up a few times as a comparison, because there the two 
features overlap heavily. That's because the language has always started 
from the opposite assumption to PHP: declarations in JS are local by 
default, and can only be referenced outside of the current function 
scope if explicitly passed outwards in some way. In PHP - and Java, C#, 
and many others - the opposite is true, and declarations have a global 
name by default; keywords like "private" and "internal" are then used to 
indicate that although code can name something, it's not allowed to use it.

Both have their strengths and weaknesses, but at this point every JS 
module going back 15+ years (CommonJS was founded in 2009, to 
standardise existing practices) is based on the "interact by export" 
model; and every PHP package going back 25+ years (PEAR founded in 1999; 
Composer in 2011) is based on the "interact by name" model.


-- 
Rowan Tommins
[IMSoP]