Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119921
Content-Type: multipart/alternative;
 boundary="------------u14ZwrJLCCghshKh6DNGFYFk"
Message-ID: <b9c47531-354f-09e4-5229-4811a3cfd470@gmail.com>
Date: Tue, 11 Apr 2023 15:15:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Content-Language: en-US
To: internals@lists.php.net
References: <CAEUnE0dGYnJMxEfaFFUUf9fm71HZMT2=BAtieGLSgopV1YsFKg@mail.gmail.com>
 <CAL0xaBFOHRBB0vyvYZUK0pt41t+U+kqbO+=4XmE3u=qSXrxk9w@mail.gmail.com>
In-Reply-To: <CAL0xaBFOHRBB0vyvYZUK0pt41t+U+kqbO+=4XmE3u=qSXrxk9w@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP Modules
From: jannesblm@gmail.com (Jannes Blume)

--------------u14ZwrJLCCghshKh6DNGFYFk
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

I’d like to give my two cents on this as I’m currently exploring “dependency hell" as part of my dissertation, including a PoC implementation of a first-class module system for PHP.

The hardest part was probably to find the least invasive way of limiting the lexical scope of global declarations like classes, free-standing functions and constants, similar to what Sara has described. I’ve ultimately decided to go with a “module.php” (manifest) file, that hosts an “export” array of said symbols that should be available to dependents. The file defines the boundaries of a “module” and all files loaded from within its directory tree will be treated according to the scoping rules defined in the manifest.

While all of this is certainly possible, I can see a lot more problems, even with a more sophisticated implementation that is supposed to be adapted by the sheer amount of Composer packages to become useful for the community. PHP developers, rightfully, make the assumption that a definition will only exist once in the current execution context, as implied by namespaces and the convention of having one prefix for a Composer package (I’m aware that we’ve had some versioning in Namespace paths previously).

> Say the mb module gets some bc breaks. We can put them into a new module so
> that the behavior is once again opt in. The strongest way to do this is to
> make composer a 1st class part of the language and let it specify the
> version of the module that is loaded.

If we’re introducing a possibility to have two or more versions of a function, class, constant, …, how can we make sure they do not clash across module boundaries? Is this the responsibility of the author when defining the public API?

I think JavaScript thrives with its module system because it’s dynamically typed and I’d argue, that because of this, developers can get away with most minor inconsistencies in behaviour between versions.
How would we combine this with strict types in PHP, that become more prevalent with each release?

I’m a supporter of the idea in general but would agree with my predecessors, that it might not be viable right now due to the scale of this. However, I am curious to hear more thoughts on this.

Jannes B

--------------u14ZwrJLCCghshKh6DNGFYFk--