On Tue, 11 Apr 2023 at 04:41, Michael Morris <tendo...@gmail.com> wrote:
> This will be long. I've read over the Future Stability thread and taken it > in, and decided to mull over an idea I touched on over a decade ago that I > think might help. Also, in the interceding years the JavaScript community > has overcome a compatibility issue using this technique, so we might do the > same. > > The crux of the stability problem is the need to update functions without > introducing a BC break. Adding in new features without removing old ones > also makes it confusing to incoming programmers as to what to use. > > I propose PHP Modules to hold new features. The existing namespace and > functions would be left alone. Existing files would also not be affected - > the behavior of PHP modules would be entirely opt in. > > They would work similar JavaScript modules - they would use the import > keyword and the include, require, include_once and require_once directives > would pitch an error if used in a PHP module. PHP Modules also would not > parse as templates at all - no opening <?php tag needed (and yes, I know > that will be a headache for IDE makers, but it's not insurmountable). > > PHP would have a new ini directive to use them similar to the "type": > "module" directive that npm uses now. If that ini directive isn't set, php > files would be handled as they always have. mphp files would always be > handled as php modules though and lphp (legacy php) would always be handled > as legacy php. > > I expect some objection to file extensions affecting parsing behavior, but > over the last 5 years this approach has worked for the JavaScript community > with cjs, mjs and js files. Here the existing php, phtml, php3, php4 > extensions are handled as the directive instructs them to be handled, only > the two new never before used extensions of lphp and mphp would do their > thing. > > In a PHP module a function has to be imported before it's used with a > handful of exceptions. The root namespace of php modules is utterly empty, > or as close to empty as makes sense. > > The existing functions would be gathered into modules so that they can be > imported. While this is done the headache inducing inconsistencies like > haystack, needle for strings and needle, haystack for arrays can be > addressed. I really don't care which is adopted, but having one order for > this language wide would be nice. Also, decide once and for all - camelCase > or underscore_case. > > The above alone would be massive. Maybe it's impossible given the number > of devs available. The one thing modules can do that the current system > cannot is allow devs to pick which version of the module to use: > > import split from 'php.mb' // imports the mbsplit() function from the > current version of PHP. > > 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. > > The import command would be able to pull from the file system or from the > import map as JavaScript does currently. For ease of dev headaches I'd > recommend hewing to the JS model as close as possible as it is proven, and > many of us already use it anyway when developing browser code. > > I hope this helps, or at least spurs a conversation to come up with > something to address this issue. > One thing I like about PHP is that it has one mainline engine implementation with a single somewhat unfragmented ecosystem and it's an autoloading killer feature with Composer backing it up. I consider that combo to be the unique trait of PHP as the language and ecosystem. You change that, you basically convert PHP into JavaScript, Go, Ruby or any other modern language that's used widely in webdev. It loses its unique traits and is why many people like it - the ecosystem. I dabbled with NPM ecosystem enough to know that I'm gonna be the NYMBY type person screaming "GET OF MY LAWN!". Just look at Python and its 2 => 3 transition saga. PHP, the project, just does not have the resources to deal with something like this and maintain multiple major versions of the language. Don't forget - JavaScript's development is backed by some of the biggest corporations on the planet with functionally limitless budgets. They can afford have 1000 people working on the JS spec, engines, browsers and nodejs to sustain it all. Not even talking the amount of resources Google sunk into V8 to the point even Microsoft just gave up on Internet Explorer and migrated now runs Edge instead. Frankly, I think a lot of people have wholly unrealistic expectations of the scale and resources available to the PHP project - it's about 8 figure sum away on a yearly basis to be able to afford all the things people want PHP to do. And it will take at least half a decade just to onboard and get people familiar with the engine enough to even start major projects. And then there are reasons that Sara has pointed out - the technical complexity alone is massive. -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Telegram: @psihius https://t.me/psihius
