Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119898 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 41461 invoked from network); 11 Apr 2023 07:47:55 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 11 Apr 2023 07:47:55 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id BD8CD18054B for ; Tue, 11 Apr 2023 00:47:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 11 Apr 2023 00:47:54 -0700 (PDT) Received: by mail-pj1-f46.google.com with SMTP id px4so4993532pjb.3 for ; Tue, 11 Apr 2023 00:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1681199273; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6FIslZ2l0oj9nz6Y/DT/kAx7YJyu8z5sJ0xDNp/7nos=; b=WINRVZVanrFJP8kSVTcKJl35gEdwD62koEUGYfSCY65uY8MqasxZtCfXtEmLsaaKfx hHPXqWb0jkVRN4ao79tyYyjlmhFP1m0j/LzpW0mXsIkRAE48dWTB05pULwRg5LjDNL+F 9+EpkPrlfvcSApjLnXsWkVeOWOcfwGU9d8XpYxeJZXE837sF3+1GNda+MkbddnLwPyOT jkwUjmssuAssF84rfa6h7oqR3XbRVi0suyXtdXRRvZ60f8YGVgIBmIWSnHNxiH/DYuzg XBKgxQhejvuWxHdVsnB03O8XWf2KmNQwUSAFRZTRw+XFCSwuAfIm6e4GZ7x05G7790oA aqnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681199273; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6FIslZ2l0oj9nz6Y/DT/kAx7YJyu8z5sJ0xDNp/7nos=; b=wxC9nS5A+aacq84L+9DVen75i1KPMgO8KiHPinAXU8py1wZuFCmmmoPzjSjecrTxrA jEd3x2QG9BAImTywujI12BgClGSr7PNwwTcpChDeI9unP3iYu0jaNZgDvZ3sDTYyoSKq iUtKehKH6FysFLowfSsq/H/zpbcfnI0FiWsLtjnKvMjfujzQxllJamc8Ly+STRUYyAzB rEXQpjb9oLyx9otNb6vZ3yo4ra64hoCXdoqKVuwkqCgNWU/Ss+2ckimtsvJ/A/1A/kbg olO9++wk6Gn+OYufcqe63T/d8KUwhLQ3IwnV9dh8aySJmHtIdSjbF5VATkRKd3u+Eh47 CuLg== X-Gm-Message-State: AAQBX9eOz0y1v6uJn6Uh2OpzhGv9uPiHPULF/OKxEbyDv94nY6+O5v5e xNFQY3mVNB+/a4EABv5AiDexfCu/jrADb8Yo2oGkvNdAGow= X-Google-Smtp-Source: AKy350Z4uUcl+knlZISXrgwYrDgRP6WV9ExK0fmtcoxWZsqkedjbYYS28x8a6ndF3HSz3snVeFivrepRd4s8Yg6At7I= X-Received: by 2002:a17:90a:3de3:b0:23f:d473:dd44 with SMTP id i90-20020a17090a3de300b0023fd473dd44mr3738998pjc.3.1681199273121; Tue, 11 Apr 2023 00:47:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 11 Apr 2023 10:47:26 +0300 Message-ID: To: Michael Morris Cc: PHP internals 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 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 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--