Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119893
MIME-Version: 1.0
Date: Mon, 10 Apr 2023 21:40:31 -0400
Message-ID: <CAEUnE0dGYnJMxEfaFFUUf9fm71HZMT2=BAtieGLSgopV1YsFKg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005b362405f90594dc"
Subject: [PHP-DEV] PHP Modules
From: tendoaki@gmail.com (Michael Morris)

--0000000000005b362405f90594dc
Content-Type: text/plain; charset="UTF-8"

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.

--0000000000005b362405f90594dc--