Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123969 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 803F31A009C for ; Thu, 27 Jun 2024 21:24:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719523535; bh=vaxjVgSIw1+i1HlJmWowMgnCJeL9odO4sgYk7CsWOQc=; h=References:In-Reply-To:From:Date:Subject:To:From; b=Z8Qc+KMViGYvolYGdN+K4IxdWMPgnix5r/sLw0mJQU1BM0Yk2328U4ax4LajtMaoc D2lRN09DZSv8YadsYSuAKZ20tHYOlXm7uNuEf5m76gyvClgMykHrGkhRuWxLuOvA9S jjS/5hl7xn+ttGNWrxayyteN3mSwVa+vUy6iYe+60YK904SJaRg8syknCDky5AqhAI LDXhxra87k+hxapI0MYl8kM1rqxXoNRcdgyYvxlbp/SRE+Ye2CcI45vc6K+Fr+WsMi G2Kynv/UG6htQ3+ClHkpqTOak8BIBKYj35OVS7smo5KQrp2bJzpJZEdyJKCPSZu0gC x5wtFgsj7zIdA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D7E101806A8 for ; Thu, 27 Jun 2024 21:25:34 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 27 Jun 2024 21:25:34 +0000 (UTC) Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-424ad991c1cso28332855e9.1 for ; Thu, 27 Jun 2024 14:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719523454; x=1720128254; darn=lists.php.net; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=q2H9SLLpsQjOgHYzLaRIDxhmX2g70MI8JWNZJAahRHc=; b=G8hSLdvbCpHAy3b9aWWXRE9tuSS1oYfsZxVBCnOK0seL/3qpyjk+C9H2wkzk/FngOo Qsch/iz+R6fzZAOxAC3QlFOLZ9zAZ9N6uKopU8BP/4j32X/+mp7Y7prR9Ly8jaka3KNZ PXSASo5kk+ikVDQkjiQyHZhM0AU57QJcSyeHAHUJsADDiK0+iFdBvxIhN0SslexM3tnR BxldkU+l2KMdoJObRGfrvccqn7LyGjQnJgOsetrsMR+5KJFFCtS5YOdxHrV1pCVMbof1 OLecBBXXG9QgvKL30HCMRLZA9J3qttPGCSI2G/d2JfsgNLRBUH6EanckiJEl5vUlY85i Llpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719523454; x=1720128254; h=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=q2H9SLLpsQjOgHYzLaRIDxhmX2g70MI8JWNZJAahRHc=; b=hv6/gu2+qnsINgyIOuyYRvENziDarcLiTEyZo0SRWkp6QErJUID3mTv4QHMlpH2hbK bZBPWw785qpKSqp2/CYBlDe16uTcTiwpE15TKfrvVQUWGo/HeoKtM7JgX+oeHD33ioDW 2IUfqTlISaODYk1qHK1p2lJcZcHvHjn13HLPjxXz9ru6+Cg3u41pGXjz2FbCMf3IGqSR Qzow0wio8N02zCobNJol8hPjf+RudVsJT/tZJAPJviLEA0y1NgyvNUGAxI79jSFHcDkN MEgHgegmTaVBQW0RePJFW0kEncho8owKa5TswbJFYTbAu+zLYtDk5tPQWLUsnk4eqRZQ 6T1Q== X-Gm-Message-State: AOJu0YzsFPXCO3hcKgCBg7eUEXfKQo1RohmEi7LMRF0rOZJhrXJL5Lu/ PznOzWOknGp7qBeIyxfuH0HYfqk9YsfzLcTpduJaV5Ex0WE5brsekcSgVh37yboUbSyDO1divUJ s0olP6MLX/48/oMSospTJf4NnwPLVkA== X-Google-Smtp-Source: AGHT+IGvbjNnEJZ0Dfzaz4ovoTfb0WyW/zUpyO5ex3V5ra112+Vprrb11+tyenDjbztY7CeSAnWguexyqyPU7qTgEG8= X-Received: by 2002:a05:6000:4013:b0:367:4dc3:7943 with SMTP id ffacd0b85a97d-3674dc37b94mr2693222f8f.71.1719523453667; Thu, 27 Jun 2024 14:24:13 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: <103583ca-2d74-4ddd-a9a4-88ea5d968b5d@app.fastmail.com> In-Reply-To: <103583ca-2d74-4ddd-a9a4-88ea5d968b5d@app.fastmail.com> Date: Thu, 27 Jun 2024 17:24:00 -0400 Message-ID: Subject: Re: Fwd: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript To: PHP internals Content-Type: multipart/alternative; boundary="000000000000a394f2061be5c0ae" From: tendoaki@gmail.com (Michael Morris) --000000000000a394f2061be5c0ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 27, 2024 at 4:55=E2=80=AFPM Rob Landers wro= te: > On Thu, Jun 27, 2024, at 21:23, Michael Morris wrote: > > > On Thu, Jun 27, 2024 at 1:02=E2=80=AFPM MKS Archive > wrote: > > > Interesting to see this. Serendipitous given the email I sent on the list > in reply to Larry. > > My initial thoughts: > > 1. I really like the concept of cleaning up issues that BC make impossibl= e > to fix by introducing modules. > > > Thanks. The sticking point is what degree of change should be occurring. > PHP isn't as behind an 8-ball as JavaScript is since the dev can choose > their PHP version and hence deprecation works most of the time for gettin= g > rid of old stuff. But not always. Changes that are incompatible with what > came before need a way to do things the old way during transition. Again, > see PHP 6 and unicode, which snowballed until it was clear that even if P= HP > 6 had been completed it wouldn't be able to run most PHP 5 code. > > > It=E2=80=99s not just up to the dev, but the libraries we use and whether= or not > we can easily upgrade (or remove) them to upgrade the php version. > > > > 2. No need for autoloaders with modules; I assume this would be obvious, > right? > > > Depends largely on whether modules can include and require to get access > to old code. I also didn't discuss how they behave - do they share their > variables with includes and requires? > > > I think it would be a mistake to exclude old code and/or prevent > templating. Not only are there now decades old code in some orgs, but how > would you write an email sender that sent templated emails, provide html, > generate code, etc? There has to be an output from the code to be useful. > > > > > 3. Not a good idea to use an ini setting; most view them to be problemati= c. > 4. .htaccess =C3=AEs Apache-only, so a non-starter anyway. > 5. The first script should not be a module. If you want that, have a 1 > line index.php file do an import. > > > I love this idea. > > Going to come back to this actually. > For example, I=E2=80=99m still going to go forward with my #[Internal] at= tribute > RFC some time in the next month or so, which will be namespace based. I > have no idea if it will pass, (some people are worried about it clashing > with an RFC like this one) but I think we=E2=80=99d have value in it for = years to > come until something like this gets fleshed out. We will see=E2=80=A6 > > What about declare? I have no idea if this would work, but.. declare(importmap=3D[ 'imports' =3D> [ 'label' : 'path', ] ] If that is put in the initial php file then it could map out the imports. An IDE could maintain the file as well. The other two attributes are scopes and integrity - the latter being a hash check for the file, scopes could be used to handle php version numbers. Multiple import maps could be defined, with each map affecting the file and whatever it imports - the seek order moving up. It would be possible to let import maps affect include and require as well. Would there be a benefit? Or just more confusion? > > > 7. Modules would have a symbol table metadata file generated by IDEs and > during deployment. > > > Node.js uses package.json and the attendant npm to do this sort of prep > work. And it's a critical part of this since modules can be versioned, a= nd > different modules may need to run different specific versions of other > modules. > > > Please, please, please do not make a json file a configuration language. > You can=E2=80=99t comment in them, you can=E2=80=99t handle =E2=80=9Cif p= hp version <9, load this, > or if this extension is installed, use this.=E2=80=9D > > Lack of comments are a problem. NodeJS does handle engine blocks, but it's messy. That said, I'm not a fan of json's popularity even in Javascript, and less so in PHP where it feels foreign. > Maybe that is desirable, but doing things slightly different based on > extensions loaded is def a thing. > > Keep in mind that extensions typically expose functions automatically, and under the original proposal those functions have to be imported to be used: `import mysql_query` Perhaps PHP imports, unlike their JavaScript or even Java C# counterparts, could be placed in try/catch blocks, with the catch resolving what to do if the import misses. > > > 8. If no metadata file in directory PHP can generate one in memory during > first directory access. > 9. .php files in modules as identified by metadata file should not be > loadable via HTTP(S). > > > Those are implementation details a little further down the road than we'r= e > ready for, I think. > > > Personally, if these are going to have any special syntax, we probably > shouldn=E2=80=99t call them .php files. Maybe .phm? > > I really don't like the extension games seen in node with js, cjs and mjs, but there's a precedent for doing it that way. In their setup if you've set modules as the default parse method then cjs can be used to identify files that still need to use CommonJS. And mjs can force the ES6 even in default mode. But it is a bit of a pain and feels like it should be avoided. > > the only thing I don=E2=80=99t like about this import/export thing is tha= t it > reminds me of the days when we had to carefully order our require_once > directives to make sure files were loaded before they were used. So, I > think it is worth thinking about how loading will work and whether loadin= g > can be dynamic, hoisted out of function calls (like js), how order matter= s, > whether packages can enrich other packages (like doctrine packages) and i= f > so, how much they can gain access to internal state, etc. This is very mu= ch > not =E2=80=9Ca solved problem.=E2=80=9D > In JavaScript import must be top of the file - you'll get an error if you try an import following any other statement unless it's a dynamic import(), which is a whole other Promise/Async/Kettle of fish that thankfully PHP does not have to take into account as, until you get used to it (and even after), async code is a headache. > > In JavaScript, arrays are instances, in php, they are values. This is > something to consider if a module exports an array of exports. > > import() (a different animal from import, yes, that is confusing, yay JavaScript) returns a promise which resolves to an object. I've slammed my head into a desk more than once over this, and it's a feature I don't want brought in. --000000000000a394f2061be5c0ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jun 27, 2024 at 4:55=E2=80=AF= PM Rob Landers <rob@bottled.codes> wrote:
<= /u>
On Thu, Jun 27, 2024, at 21:23, Michael Morris wrote:
=

On T= hu, Jun 27, 2024 at 1:02=E2=80=AFPM MKS Archive <mikeschinkel@gmail.com> wrote:<= br>

Interesting to see this. Serendipitous= given the email I sent on the list in reply to Larry.

My initial thoughts:

1. I really like= the concept of cleaning up issues that BC make impossible to fix by introd= ucing modules.

Thanks. The = sticking point is what degree of change should be occurring. PHP isn't = as behind an 8-ball as JavaScript is since the dev can choose their PHP ver= sion and hence deprecation works most of the time for getting rid of old st= uff. But not always. Changes that are incompatible with what came before ne= ed a way to do things the old way during transition. Again, see PHP 6 and u= nicode, which snowballed until it was clear that even if PHP 6 had been com= pleted it wouldn't be able to run most PHP 5 code.

It=E2=80=99s not just up to t= he dev, but the libraries we use and whether or not we can easily upgrade (= or remove) them to upgrade the php version.

=C2=A0
2= . No need for autoloaders with modules; I assume this would be obvious, rig= ht?


Depends = largely on whether modules can include and require to get access to old cod= e. I also didn't discuss how they behave - do they share their variable= s with includes and requires?

I think it would be a mistake to exclude old code and/= or prevent templating. Not only are there now decades old code in some orgs= , but how would you write an email sender that sent templated emails, provi= de html, generate code, etc? There has to be an output from the code to be = useful.=C2=A0

=C2=A0
=

3. Not a good id= ea to use an ini setting; most view them to be problematic.
4= . .htaccess =C3=AEs Apache-only, so a non-starter anyway.
5. = The first script should not be a module. If you want that, have a 1 line in= dex.php file do an import.

= I love this idea.=C2=A0

Going to come back to this actually= .=C2=A0
For example, I=E2=80=99m still going to go forward with my #[Inte= rnal] attribute RFC some time in the next month or so, which will be namesp= ace based. I have no idea if it will pass, (some people are worried about i= t clashing with an RFC like this one) but I think we=E2=80=99d have value i= n it for years to come until something like this gets fleshed out. We will = see=E2=80=A6=C2=A0


What about declare?=C2=A0 I have no idea if this would work, but..=

declare(importmap=3D[
=C2=A0 'imports'= ; =3D> [
=C2=A0 =C2=A0 'label' : 'path',
=
=C2=A0 ]
]

If that is put in the in= itial php file then it could map out the imports. An IDE could maintain the= file as well.=C2=A0 The other two attributes are scopes and integrity - th= e latter being a hash check for the file, scopes could be used to handle ph= p version numbers. Multiple import maps could be defined, with each map aff= ecting the file and whatever it imports - the seek order moving up.

It would be possible to let import maps affect include an= d require as well. Would there be a benefit? Or just more confusion?
<= div>=C2=A0
=C2= =A0
7. Modules would have a = symbol table metadata file generated by IDEs and during deployment.

Node.js uses package.json and the = attendant npm to do this sort of prep work.=C2=A0 And it's a critical p= art of this since modules can be versioned, and different modules may need = to run different specific versions of other modules.
<= /div>

Please, please, please do not m= ake a json file a configuration language. You can=E2=80=99t comment in them= , you can=E2=80=99t handle =E2=80=9Cif php version <9, load this, or if = this extension is installed, use this.=E2=80=9D


Lack of comments are a problem.=C2=A0 N= odeJS does handle engine blocks, but it's messy. That said, I'm not= a fan of json's popularity even in Javascript, and less so in PHP wher= e it feels foreign.
=C2=A0
Mayb= e that is desirable, but doing things slightly different based on extension= s loaded is def a thing.=C2=A0

=
Keep in mind that extensions typically expose functions auto= matically, and under the original proposal those functions have to be impor= ted to be used: `import mysql_query`

Perhaps PHP i= mports, unlike their JavaScript or even Java C# counterparts, could be plac= ed in try/catch blocks, with the catch resolving what to do if the import m= isses.
=C2=A0
<= div>
=C2=A0
8. If no=C2= =A0metadata file in directory PHP can generate one in memory during first d= irectory access.=C2=A0
9. .php files in modules as identified= by metadata file should not be loadable via HTTP(S).=C2=A0
=

Those are implementation details a little = further down the road than we're ready for, I think.=C2=A0

Personally, if these = are going to have any special syntax, we probably shouldn=E2=80=99t call th= em .php files. Maybe .phm?


=
I really don't like the extension games seen in node with js= , cjs and mjs, but there's a precedent for doing it that way.=C2=A0 In = their setup if you've set modules as the default parse method then cjs = can be used to identify files that still need to use CommonJS.=C2=A0 And mj= s can force the ES6 even in default mode.=C2=A0 But it is a bit of a pain a= nd feels like it should be avoided.
=C2=A0

the only thing I don=E2=80=99t like about this i= mport/export thing is that it reminds me of the days when we had to careful= ly order our require_once directives to make sure files were loaded before = they were used. So, I think it is worth thinking about how loading will wor= k and whether loading can be dynamic, hoisted out of function calls (like j= s), how order matters, whether packages can enrich other packages (like doc= trine packages) and if so, how much they can gain access to internal state,= etc. This is very much not =E2=80=9Ca solved problem.=E2=80=9D

In JavaScript import must be top of th= e file - you'll get an error if you try an import following any other s= tatement unless it's a dynamic import(), which is a whole other Promise= /Async/Kettle of fish that thankfully PHP does not have to take into accoun= t as, until you get used to it (and even after), async code is a headache.<= /div>
=C2=A0

In JavaScript, array= s are instances, in php, they are values. This is something to consider if = a module exports an array of exports.=C2=A0


import() (a different animal from import, yes, = that is confusing, yay JavaScript) returns a promise which resolves to an o= bject. I've slammed my head into a desk more than once over this, and i= t's a feature I don't want brought in.
=C2=A0
= --000000000000a394f2061be5c0ae--