Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119898
MIME-Version: 1.0
References: <CAEUnE0dGYnJMxEfaFFUUf9fm71HZMT2=BAtieGLSgopV1YsFKg@mail.gmail.com>
In-Reply-To: <CAEUnE0dGYnJMxEfaFFUUf9fm71HZMT2=BAtieGLSgopV1YsFKg@mail.gmail.com>
Date: Tue, 11 Apr 2023 10:47:26 +0300
Message-ID: <CAL0xaBFOHRBB0vyvYZUK0pt41t+U+kqbO+=4XmE3u=qSXrxk9w@mail.gmail.com>
To: Michael Morris <tendoaki@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000789f7205f90ab517"
Subject: Re: [PHP-DEV] PHP Modules
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--000000000000789f7205f90ab517
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 11 Apr 2023 at 04:41, Michael Morris <tendoaki@gmail.com> wrote:

> This will be long. I've read over the Future Stability thread and taken i=
t
> 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 t=
he
> 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 directive=
s
> 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, ph=
p
> 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 handl=
ed
> as legacy php.
>
> I expect some objection to file extensions affecting parsing behavior, bu=
t
> over the last 5 years this approach has worked for the JavaScript communi=
ty
> with cjs, mjs and js files.  Here the existing php, phtml, php3, php4
> extensions are handled as the directive instructs them to be handled, onl=
y
> 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 - camelCa=
se
> 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 t=
o
> 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, an=
d
> 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 =3D> 3 transition saga. PHP, the project, jus=
t
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.

--=20

Arv=C4=ABds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

--000000000000789f7205f90ab517--