Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123974 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 17AF51AD8EA for ; Thu, 27 Jun 2024 21:56:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719525479; bh=n26uAkjpKlxtzTdkXbdx9Wwm9f/G2JjbfYCm4AXEdaE=; h=In-Reply-To:References:Date:From:To:Subject:From; b=OdPfVA2KDSt/RaOrY5da+xcDUNJ9eJZAn+IUQ6vVt8ohaI+V3NtpWQhO1QwcKaC0h h25Y7/bpy22v/LJmcgsrmxMfkjc9G6o2klj/R3ep0xxSgNWJFrdn3MuOBRHb68SsXC RxX6Uain89QKKd9nkTc3LWc+nMAk3gr6ZsPVwdv4tJa742rpi3303DKNX43auJNw2r FLDXVF3sWW9Ie8IQoLiYZwD08/LRyOrn0EftwFjdURyHkwNLzpxFYPhsA5BRPErGBc eVhaH+ImppXZVHyLh570O91SEXDYz1fdFP307j8VJXt2/pCJkLvyYByshSjFiSX144 Fsd2p+9cr3LXQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 102B3181AD8 for ; Thu, 27 Jun 2024 21:57:55 +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.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,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 wfhigh1-smtp.messagingengine.com (wfhigh1-smtp.messagingengine.com [64.147.123.152]) (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:57:52 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfhigh.west.internal (Postfix) with ESMTP id 2250C18000AC for ; Thu, 27 Jun 2024 17:56:33 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute1.internal (MEProxy); Thu, 27 Jun 2024 17:56:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1719525392; x=1719611792; bh=nRFhcYTXhn /mTu2mMV0NCmNFmbN+NbryembS4a7raLY=; b=VO2I7KwrEiMfIJ7NbhqU39PWnZ ujRIbzgGyoP5GUDZg66imVfA0YkhDLoJS3BZiTadn/smykG9gmLUvZMik8x4GS4R suIbzSyVhFjT6A+7/AGwKixeXbF7DNR+M8XcfPcd7bzqjXCx26w8WoafJokVAXm0 y9ka19iLXqdiW3cBIueGEZ20rJ6wcUyzvftZ0rovtp/tPvhdSt55cjU6lCmvqz5E lFsO8AtZghjqP7pHwxGn+F8NInFAzh0QZYffbE5fjuuUnzRxuV2Cv5KcoZchFOAl KAYiN96VTdCtHJajYEMofpKUfi6eV7xRFif/5rui3K7a+5kgr2OQ9DArRfmA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1719525392; x=1719611792; bh=nRFhcYTXhn/mTu2mMV0NCmNFmbN+ NbryembS4a7raLY=; b=VkefqHyBlPzsqG+MYvcgKJs+9AYKd6IZju5z6FCZDsyk eTzrXOvVyPxhFMQvAWqIkKhdv5uQbU0gMf2ZiqpPtdomlh/WOoStEbB68LPzL+Cb 7EcQxjRIzZ26wrjQWHIT6xUsQ9LXo03netLs2GIzqC9+N4K0y3ah8KNGkVxfafMv akg19UcOPpEiuaX9M7nU9jkDC/ARR6RpElPF8I/zKrqtLKBH5TQxfhIIcgu2VYx5 S+wbin/rACX0xCN8KcVLmuypkXmT7uq0Y6UWEaKdb4/I7YfNhEu5yY1TSutD2AI2 IQAig7JK+GSnMXTp8FuDgCtOVi0g2lnRyob9YNYeAA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrtdehgddtgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdftohgsucfnrghnuggvrhhsfdcuoehrohgssegsohhtthhl vggurdgtohguvghsqeenucggtffrrghtthgvrhhnpeegueejueeiteelieeggffhtddvff evuefhleeghfeukedvveehvedthffhueevkeenucffohhmrghinhepfiefshgthhhoohhl shdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehrohgssegsohhtthhlvggurdgtohguvghs X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 78EBC15A0093; Thu, 27 Jun 2024 17:56:32 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-538-g1508afaa2-fm-20240616.001-g1508afaa Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 Message-ID: <36b1a9ab-2a9a-486a-b000-5dd20642d4e5@app.fastmail.com> In-Reply-To: References: <103583ca-2d74-4ddd-a9a4-88ea5d968b5d@app.fastmail.com> Date: Thu, 27 Jun 2024 23:56:10 +0200 To: internals@lists.php.net Subject: Re: Fwd: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript Content-Type: multipart/alternative; boundary=c1cd60b9286b49c69e1838287245f728 From: rob@bottled.codes ("Rob Landers") --c1cd60b9286b49c69e1838287245f728 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 27, 2024, at 23:24, Michael Morris wrote: >=20 >=20 > On Thu, Jun 27, 2024 at 4:55=E2=80=AFPM Rob Landers wrote: >> __ >> On Thu, Jun 27, 2024, at 21:23, Michael Morris wrote: >>>=20 >>> On Thu, Jun 27, 2024 at 1:02=E2=80=AFPM MKS Archive wrote: >>>>>=20 >>>> Interesting to see this. Serendipitous given the email I sent on th= e list in reply to Larry. >>>>=20 >>>> My initial thoughts: >>>>=20 >>>> 1. I really like the concept of cleaning up issues that BC make imp= ossible to fix by introducing modules. >>>=20 >>> Thanks. The sticking point is what degree of change should be occurr= ing. PHP isn't as behind an 8-ball as JavaScript is since the dev can ch= oose their PHP version and hence deprecation works most of the time for = getting 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 transit= ion. Again, see PHP 6 and unicode, which snowballed until it was clear t= hat even if PHP 6 had been completed it wouldn't be able to run most PHP= 5 code. >>=20 >> It=E2=80=99s not just up to the dev, but the libraries we use and whe= ther or not we can easily upgrade (or remove) them to upgrade the php ve= rsion. >>=20 >>> =20 >>>> 2. No need for autoloaders with modules; I assume this would be obv= ious, right? >>>>=20 >>>=20 >>> Depends largely on whether modules can include and require to get ac= cess to old code. I also didn't discuss how they behave - do they share = their variables with includes and requires? >>=20 >> I think it would be a mistake to exclude old code and/or prevent temp= lating. Not only are there now decades old code in some orgs, but how wo= uld 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= .=20 >>=20 >>> =20 >>>>=20 >>>> 3. Not a good idea to use an ini setting; most view them to be prob= lematic. >>>> 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. >>>=20 >>> I love this idea.=20 >>>=20 > Going to come back to this actually.=20 >>>=20 >> For example, I=E2=80=99m still going to go forward with my #[Internal= ] attribute RFC some time in the next month or so, which will be namespa= ce 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 va= lue in it for years to come until something like this gets fleshed out. = We will see=E2=80=A6=20 >>=20 >=20 > What about declare? I have no idea if this would work, but.. >=20 > declare(importmap=3D[ > 'imports' =3D> [ > 'label' : 'path', > ] > ] >=20 > If that is put in the initial php file then it could map out the impor= ts. An IDE could maintain the file as well. The other two attributes ar= e scopes and integrity - the latter being a hash check for the file, sco= pes could be used to handle php version numbers. Multiple import maps co= uld be defined, with each map affecting the file and whatever it imports= - the seek order moving up. >=20 > It would be possible to let import maps affect include and require as = well. Would there be a benefit? Or just more confusion? Internals has made it pretty clear: no more declare or ini entries (unle= ss it is absolutely needed). I personally don=E2=80=99t like it because it uses arrays, which are opa= que, easy to typo, and hard to document/check. Instead, maybe consider a new Reflection API? (new ReflectionModule)->import('MyModule')->run() From the index.php file (where =E2=80=9Crun=E2=80=9D is an exported func= tion and can take arguments, like $argv, request objects, globals, etc). Inside modules, we would have the import syntax (which could arguably be= compiled to the above code, more-or-less).=20 > =20 >>=20 >>> =20 >>>> 7. Modules would have a symbol table metadata file generated by IDE= s and during deployment. >>>=20 >>> Node.js uses package.json and the attendant npm to do this sort of p= rep work. And it's a critical part of this since modules can be version= ed, and different modules may need to run different specific versions of= other modules. >>=20 >> Please, please, please do not make a json file a configuration langua= ge. You can=E2=80=99t comment in them, you can=E2=80=99t handle =E2=80=9C= if php version <9, load this, or if this extension is installed, use thi= s.=E2=80=9D >>=20 >=20 > 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 Javas= cript, and less so in PHP where it feels foreign. > =20 >>=20 >> Maybe that is desirable, but doing things slightly different based on= extensions loaded is def a thing.=20 >>=20 >=20 > 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` they also do now, unless you either prefix them with \ or rely on the fa= llback resolution system. I=E2=80=99m honestly not sure we need a new sy= ntax for this, but maybe just disable the global fallback system in modu= les? >=20 > Perhaps PHP imports, unlike their JavaScript or even Java C# counterpa= rts, could be placed in try/catch blocks, with the catch resolving what = to do if the import misses. Right now, I usually see if(function_exists('some_func_from_extension'))= , so as long as imports behave as they currently do =E2=80=94 not actual= ly triggering any loading =E2=80=94 then this would still work just fine= .=20 > =20 >>=20 >>> =20 >>>> 8. If no metadata file in directory PHP can generate one in memory = during first directory access.=20 >>>> 9. .php files in modules as identified by metadata file should not = be loadable via HTTP(S).=20 >>>=20 >>> Those are implementation details a little further down the road than= we're ready for, I think.=20 >>=20 >> Personally, if these are going to have any special syntax, we probabl= y shouldn=E2=80=99t call them .php files. Maybe .phm? >>=20 >=20 > 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 y= ou've set modules as the default parse method then cjs can be used to id= entify 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 shou= ld be avoided. I would argue that it be something seriously considered. Scanning a dire= ctory in the terminal, in production systems, while diagnosing ongoing p= roduction issues, it can be very handy to distinguish between the =E2=80= =9Cold way=E2=80=9D and =E2=80=9Cnew way=E2=80=9D, at a glance.=20 > =20 >>=20 >>=20 >> the only thing I don=E2=80=99t like about this import/export thing is= that it reminds me of the days when we had to carefully order our requi= re_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 whethe= r loading can be dynamic, hoisted out of function calls (like js), how o= rder matters, whether packages can enrich other packages (like doctrine = packages) and if so, how much they can gain access to internal state, et= c. This is very much not =E2=80=9Ca solved problem.=E2=80=9D >=20 > 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 im= port(), which is a whole other Promise/Async/Kettle of fish that thankfu= lly PHP does not have to take into account as, until you get used to it = (and even after), async code is a headache. Are you sure? I don=E2=80=99t remember them removing import hoisting, bu= t it=E2=80=99s probably more of a typical linting rule because it is har= d to reason about.=20 https://www.w3schools.com/js/js_hoisting.asp In other news, async in PHP is alive and well. Fibers are a thing and sw= oole just announced threading.=20 > =20 >>=20 >> In JavaScript, arrays are instances, in php, they are values. This is= something to consider if a module exports an array of exports.=20 >>=20 >=20 > 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. > =20 =E2=80=94 Rob --c1cd60b9286b49c69e1838287245f728 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable

=
On Thu, Jun 27, 2024, at 23:24, Michael Morris wrote:
=


On Thu, Jun 27, 2024 at 4:55=E2=80= =AFPM Rob Landers <rob@bottled.codes> wrote:

On Thu, Jun = 27, 2024, at 21:23, Michael Morris wrote:

On Thu, Jun 27, 2= 024 at 1:02=E2=80=AFPM MKS Archive <mikeschinkel@gmail.com> wrote:

Interesting to see t= his. 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 introducing modules.

Thanks. The sticking point is what degree of change sh= ould 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 getting 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 PHP 6 had been completed it wouldn't be able t= o 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 upgr= ade the php version.

=
 
2. No need for autoloaders with modules; I assume this would = be obvious, right?


<= /div>
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?
<= /div>

I think it would be a mistak= e 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 t= hat sent templated emails, provide html, generate code, etc? There has t= o be an output from the code to be useful. 

 

3. Not a good idea t= o 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 li= ne index.php file do an import.

I love this idea. 

Going to come back to= this actually. 
=

For e= xample, I=E2=80=99m still going to go forward with my #[Internal] attrib= ute 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 clas= hing with an RFC like this one) but I think we=E2=80=99d have value in i= t for years to come until something like this gets fleshed out. We will = see=E2=80=A6 


<= /div>
What about declare?  I have no idea if this would work, b= ut..

declare(importmap=3D[
&n= bsp; 'imports' =3D> [
    'label' : 'path',
  ]
]

If th= at 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, scope= s could be used to handle php version numbers. Multiple import maps coul= d be defined, with each map affecting the file and whatever it imports -= the seek order moving up.

It would be poss= ible to let import maps affect include and require as well. Would there = be a benefit? Or just more confusion?
=

Internals has made it pretty clear: no more declare = or ini entries (unless it is absolutely needed).

I personally don=E2=80=99t like it because it uses arrays, which a= re opaque, easy to typo, and hard to document/check.

<= /div>
Instead, maybe consider a new Reflection API?
(new ReflectionModule)->import('MyModule')->run()
=

From the index.php file (where =E2=80=9Crun=E2= =80=9D is an exported function and can take arguments, like $argv, reque= st objects, globals, etc).

Inside modules, = we would have the import syntax (which could arguably be compiled to the= above code, more-or-less). 

 
 
7. Modules would have a sy= mbol 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 critica= l part of this since modules can be versioned, and different modules may= need to run different specific versions of other modules.

Please, please, ple= ase 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 php version <9,= load this, or if this extension is installed, use this.=E2=80=9D


Lack of comment= s 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 l= ess so in PHP where it feels foreign.
 

Maybe that is d= esirable, but doing things slightly different based on extensions loaded= is def a thing. 

<= br>
Keep in mind that extensions typically expose functions au= tomatically, and under the original proposal those functions have to be = imported to be used: `import mysql_query`

they also do now, unless you either prefix them = with \ or rely on the fallback resolution system. I=E2=80=99m honestly n= ot sure we need a new syntax for this, but maybe just disable the global= fallback system in modules?


Perhaps PHP imports, unlike their JavaScript or e= ven Java C# counterparts, could be placed in try/catch blocks, with the = catch resolving what to do if the import misses.

Right now, I usually see if(function_exis= ts('some_func_from_extension')), so as long as imports behave as they cu= rrently do =E2=80=94 not actually triggering any loading =E2=80=94 then = this would still work just fine. 

 

 
<= blockquote style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;ma= rgin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-lef= t-color:rgb(204, 204, 204);padding-left:1ex;">
8. If no me= tadata file in directory PHP can generate one in memory during first dir= ectory access. 
9. .php files in modules as identifie= d by metadata file should not be loadable via HTTP(S). 

Those are implementation details a = little further down the road than we're 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 se= en in node with js, cjs and mjs, but there's a precedent for doing it th= at 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 Com= monJS.  And mjs can force the ES6 even in default mode.  But i= t is a bit of a pain and feels like it should be avoided.

I would argue that it be somethi= ng seriously considered. Scanning a directory in the terminal, in produc= tion systems, while diagnosing ongoing production issues, it can be very= handy to distinguish between the =E2=80=9Cold way=E2=80=9D and =E2=80=9C= new way=E2=80=9D, at a glance. 

 


the only thing I don=E2=80=99t like about= this import/export thing is that it reminds me of the days when we had = to carefully order our require_once directives to make sure files were l= oaded before they were used. So, I think it is worth thinking about how = loading will work and whether loading can be dynamic, hoisted out of fun= ction calls (like js), how order matters, whether packages can enrich ot= her packages (like doctrine packages) and if so, how much they can gain = access to internal state, etc. This is very much not =E2=80=9Ca solved p= roblem.=E2=80=9D

In Java= Script import must be top of the file - you'll get an error if you try a= n import following any other statement unless it's a dynamic import(), w= hich is a whole other Promise/Async/Kettle of fish that thankfully PHP d= oes not have to take into account as, until you get used to it (and even= after), async code is a headache.

Are you sure? I don=E2=80=99t remember them removing im= port hoisting, but it=E2=80=99s probably more of a typical linting rule = because it is hard to reason about. 

<= a href=3D"https://www.w3schools.com/js/js_hoisting.asp">https://www.w3sc= hools.com/js/js_hoisting.asp

In other n= ews, async in PHP is alive and well. Fibers are a thing and swoole just = announced threading. 

 

In JavaScript, arrays are instances, in php, they are values. Thi= s is something to consider if a module exports an array of exports. = ;


import(= ) (a different animal from import, yes, that is confusing, yay JavaScrip= t) returns a promise which resolves to an object. I've slammed my head i= nto a desk more than once over this, and it's a feature I don't want bro= ught in.
 


=E2=80=94 = Rob
--c1cd60b9286b49c69e1838287245f728--