Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123986 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 BE3121A009C for ; Fri, 28 Jun 2024 11:46:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719575276; bh=H0b6Tsra1++90VPT2eO7NauZeBj9+TrvXpUWJ+7gTTU=; h=In-Reply-To:References:Date:From:To:Subject:From; b=HP7hDrubjU6nV2GjWxARcLtqqb/05LhrofyqihUS4hfqED1b5jnmJaNLj02sW9zKW tQnKyHCldAf3cD639GEX48zN6tq3t+wRgrvE2zw33DDDWrw/fzlvZ4vEE3ka5bvIoO MHIKD4tkhfdK4QFzPNHofBowyd58VKK2y51Bt0fajgW/AWJp2ULv4arfTWCJhbgiIM 0iuBGhTWNKwwoMrzbEYvS0ZWAw5LwE8yvNl1ltlEgpSXMEpC8qOqA1buYXDjbfGO6b 8q9PbYtH3eVElcFm7duA/WHShB0jNA8vOnPc+YF99k87d4rNrPGi/MjUGFfj0QQYXO RlNgzY7PkyqRQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B7ACB180003 for ; Fri, 28 Jun 2024 11:47:54 +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 fhigh1-smtp.messagingengine.com (fhigh1-smtp.messagingengine.com [103.168.172.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 ; Fri, 28 Jun 2024 11:47:54 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfhigh.nyi.internal (Postfix) with ESMTP id DCCB2114035F for ; Fri, 28 Jun 2024 07:46:34 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute1.internal (MEProxy); Fri, 28 Jun 2024 07:46:34 -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=1719575194; x=1719661594; bh=OZLPOGY7iL kAN9J7buUN+YvzBRnEPU7cWQ6y/zL1mhU=; b=sVVtJIDTTOqqewFgKnbwLukval xszOa7ey2SEPk7bn6MPI3ouc/dXEgZp7YM5VcHyZ+jKVpPRHo7HYO6V5o8J4i9cK f0jFnpRBfXn1c8DhagwyhcYgsMg4Z2/eq/R9rElC1QhgNp7ifH2uUtroD6DO3ZQy Yh7v3qYYWlD6t+FEZ3NOY/07XlBpS6x5vUA2PWe2vR/UgtwGc4tPaSrArKOHRnUd EpvKa29qogxePjY+oGuqy1h3vzK8VdNAK5PCMGlVctxARIPnjqt6jur0nu7Q6Y6X PNGsz0QvqpT/pcXk7GA3qL01FUSxCO9FHrc6xh71lkbkyozH/nkeXw+3bPNw== 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=1719575194; x=1719661594; bh=OZLPOGY7iLkAN9J7buUN+YvzBRnE PU7cWQ6y/zL1mhU=; b=vmS2o2N3Bn99BTzEheHzW9+7Nb7eBrIkf7Aflip9Er4B zdRVW0jFOMfhAFhmvjOHnO2sTsnHkKc5/ownuGSG1TUn6AaDr7DzR+NTLnznb+xF HRyXD2gcuTjbGoDYIG8xqhWymjDX07/MY4y44vnFVtogpnfAJ1yAnVkZUsS8NCjf ESIwer1beP8ptK4O2or9Vdsxa2vOuhEXXJa/xirWklny0ry/R399ekATCHTpULtF rSsc0/nP1T5fnRSVOUe1faM/Ylic5oTkDXmV9CWPKoCGcqs6LeZZ3x27R4JFjnD4 RR422wOZ9XlWGH65yerAQlGd0K0v1SM/XIPFBfGa2A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrtdeigdegvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdftohgsucfnrghnuggvrhhsfdcuoehrohgssegsohhtthhl vggurdgtohguvghsqeenucggtffrrghtthgvrhhnpeeffeduhfduudeikeekudfghfdugf eljefgkeeghfdvieekledvvdejheetgeetgeenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehrohgssegsohhtthhlvggurdgtohguvghs X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7F69315A0092; Fri, 28 Jun 2024 07:46:34 -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: <920f33e5-0a2e-436c-86e8-e4bbd699e47b@app.fastmail.com> In-Reply-To: References: <0acedb8e-34be-4348-907b-4075cf7641fd@app.fastmail.com> <9c20b078-f82a-47fe-af23-2f3cdd233079@app.fastmail.com> Date: Fri, 28 Jun 2024 13:45:51 +0200 To: internals@lists.php.net Subject: Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript Content-Type: multipart/alternative; boundary=0d104b6dd3b0487587ebce65fa8d7bfb From: rob@bottled.codes ("Rob Landers") --0d104b6dd3b0487587ebce65fa8d7bfb Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Jun 28, 2024, at 09:07, Michael Morris wrote: > This is a very long reply to several emails. >=20 > On Thu, Jun 27, 2024 at 5:45=E2=80=AFPM Jim Winstead wrote: >> __ >> The angle I am coming at this from is improving the developer experie= nce around "packages" or "modules" or whatever you want to call them, an= d so much of this proposal doesn't seem to be about that. >>=20 >=20 > Ok, first problem - not a proposal really, but a ramble trying to get = to a proposal. Before I made the first post the idea was knocking around= in my head and wouldn't go away, so I just stream of consciousness list= ed what's going through my head. That leads to the second point you made. > =20 >>=20 >> I could have made that point in other ways, and I'm sorry that my fir= st attempt came off as insulting. It really concerned me when I already = saw discussion about taking this off-list and going into the weeds on te= chnical details when the problem that is being addressed by this proposa= l is extremely unclear to me. >=20 > It is unclear even to me. Perhaps I shouldn't have posted out somethi= ng this half baked. That said, pruning off large sections of language fu= nctionality is a distraction. For now let's just note that it is a possi= bility to improve the language this way afforded by the fact that import= would be new way of bringing scripts in. Could isn't should. Also, at= the moment again it's a distraction. Let's focus down on how code is im= ported. >=20 > First though, a history review, partially to get this straight in my o= wn head but hopefully of use for those following along. Why? Knowing how= we got we are is important to some degree to chart a way forward. >=20 > PHP started as a template engine. By modern standards, and compared to= the likes of twig, it's a very bad template engine, but that doesn't re= ally matter because it's evolved into a programming language in it's own= right over the last nearly 20 years. How do you think twig works, exactly? You should probably check it out, = because templates compile down to regular PHP templates -- at least it d= id the last time I looked at it a few years ago. How do you think emails= are templated by php code? How do you think anything is output? By eith= er "echo" or ?> content =20 > Include, include_once, require, and require_once have been around sinc= e the beginning as the way to splice code files together. The behavior o= f these statements calls back to PHP's origin as a template engine as th= ey do things similar mechanisms like JavaScript's import do not do (and = for that matter, their equivalents in C# and Java). Their scope behavior= is very different from import mechanisms in other languages, as they se= e the variables in the scope of the function they were invoked from or t= he global scope when called from there. Their parsing can be aborted ea= rly with a return. They can return a value, which is quite unusual to b= e honest. None of this is bad per se, but it is different and the questi= on arises is it necessary. How do you think javascript import works, exactly? They load a file whic= h returns a value via export. There is nothing inherently wrong with requires/includes, it's literally= required by every language via some mechanism or another (C's include s= tatements, go's go.mod file, javascripts import/package.json, C#'s proje= ct config, etc). There's no magical thing here, just abstractions and di= fferent levels of it. >=20 > One artifact of their behavior that is bad in my opinion is that they = start from the standpoint of being text or html files. =20 Every single language starts with a text file... There's nothing inheren= tly special about the bytes in any source code file and they only have m= eaning due to creating a parser that can make sense of the stream of byt= es. The fact that they also have meaning to humans is what makes it sour= ce code and not object code/byte code. > If the included file has no PHP tags then the contents get echoed out.= If there are no output buffers running this can cause headers to be set= and fun errors to be had. So they can't be used to create files that ca= n only echo explicitly (that is, a call to the echo statement or the lik= e). For headers, this is largely up to the SAPI (the program that executes t= he PHP code, eg, frankenphp, php-fpm, mod-cgi, roadrunner, etc) and the = fact that most SAPIs want to be able to run existing code where develope= rs have certain expectations of behavior. FrankenPHP did a little someth= ing different with the support of the 103 status code which isn't suppor= ted in any other SAPI (AFAIK). The CLI sapi doesn't output any headers w= hatsoever. As far as PHP opening tags go... I don't even notice it. They're there, = just like the "package" declaration on the top of every one of my Go fil= es. >=20 > Fast forward a bit - PHP 5.3, and the introduction of namespaces were = introduced to deal with the overloaded symbol tables. They are a bit a h= otwire as (if I'm not mistaken, it's been a couple years since I read th= e discussion on it) they just quietly prepend the namespace string in fr= ont of the name of all new symbols declared in the namespace for use els= ewhere. As a result, PHP namespaces don't do some of the things we see i= n the namespaces of other languages (looking at Java and C# here). For e= xample, privacy modifiers within a namespace aren't a thing. This would be nice to have ... maybe. But namespace have been around, wh= at, 10-15 years? I think if someone wanted to "fix" it, it would have be= en fixed by now. >=20 > Very quickly after PHP 5.3 released autoloaders showed up. At some poi= nt support for multiple autoloaders was added. Several schema were adde= d, PSR-4 won out, and composer showed up to leverage this. Composer is b= ased on NPM, even to the point where json is used to configure it, and t= he composer.json file is fairly close to npm's package.json file even no= w. It's a userland solution, but to my knowledge WordPress is the only = widely used PHP application out there that doesn't use it directly (ther= e is a Composer Wordpress project). WordPress predates composer et. al., by more than 10 years (if you count= the B2 code it was forked from). Why would it use it? From working at A= utomattic (I left a couple of years ago, and this is merely what I saw a= s an observer, I wasn't closely involved with any of the open-source sid= e), there was a bit of a push to make it happen as it looked like Compos= er would be around for awhile, but then there was talk about an "officia= l" loader/thing from php itself and I think they'd rather use that inste= ad. When you have a project that has literally been around decades, you = don't change out your whole system on the whims of what is fashionable a= t the time; you either innovate or wait and see what becomes standard. C= omposer has only been around 50% of the time WordPress has been around n= ow; and it didn't start out as immediately popular. > Before composer, and before namespaces there was PECL. Composer has e= clipsed it because PECL has the limitation of being server-wide. It neve= r really caught on in the age of virtual hosting with multiple PHP sites= running on one box. Today we have Docker, but that didn't help PECL mak= e a comeback because by the time docker deployment of PHP sites became t= he norm composer had won out. Also, composer library publishing is more= permissive than PECL. I'll stop here lest this digress into a Composer = v PECL discussion - suffice to say stabs a bringing code packages into P= HP isn't a new idea, and a survey of what's been done before, what was r= ight about those attempts and what was wrong needs to be considered befo= re adding yet another php package system into the mix. I don't think PECL and Composer have much in common... at all. Like they= are not even comparable, and it is still the best way to install extens= ions (in fact, it is the only way in a docker container AFAIK) on a self= -compiled php. > The main influence of composer and autoloaders for preparing packages = is that PHP has become far more Object Oriented than it was before. Pri= or to PHP 5.3 object oriented programming was a great option, but since = autoloaders cannot bring in functions (at least not directly, they can b= e cheated in by bundling them in static classes which are all but namesp= aces) the whole ecosystem has become heavily object oriented. require/include still works fine, or using the "file" key on the autoloa= der in composer.json. I don't find most of these "problems" actually valid. There is some meri= t to the conclusions, but the premise feels shaky. =E2=80=94 Rob --0d104b6dd3b0487587ebce65fa8d7bfb Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 28,= 2024, at 09:07, Michael Morris wrote:
This is a very = long reply to several emails.

On Thu, Jun 27, 202= 4 at 5:45=E2=80=AFPM Jim Winstead <jimw@trainedmonkey.com> wrote:

The angle I am coming at this from is improving the develo= per experience around "packages" or "modules" or whatever you want to ca= ll them, and so much of this proposal doesn't seem to be about that.
=


Ok, first problem - not a proposal really, but a = ramble trying to get to a proposal. Before I made the first post the ide= a was knocking around in my head and wouldn't go away, so I just stream = of consciousness listed what's going through my head. That leads to the = second point you made.
 

<= div style=3D"font-family:Arial;">I could have made that point in other w= ays, and I'm sorry that my first attempt came off as insulting. It reall= y concerned me when I already saw discussion about taking this off-list = and going into the weeds on technical details when the problem that is b= eing addressed by this proposal is extremely unclear to me.

 It is unclear even to me= . Perhaps I shouldn't have posted out something this half baked. That sa= id, pruning off large sections of language functionality is a distractio= n. For now let's just note that it is a possibility to improve the langu= age this way afforded by the fact that import would be new way of bringi= ng scripts in.  Could isn't should.  Also, at the moment again= it's a distraction. Let's focus down on how code is imported.
=

First though, a history review, partially to get thi= s straight in my own head but hopefully of use for those following along= . Why? Knowing how we got we are is important to some degree to chart a = way forward.

PHP started as a template engi= ne. By modern standards, and compared to the likes of twig, it's a = very bad template engine, but that doesn't really matter because it's ev= olved into a programming language in it's own right over the last nearly= 20 years.

How do = you think twig works, exactly? You should probably check it out, because= templates compile down to regular PHP templates -- at least it did the = last time I looked at it a few years ago. How do you think emails are te= mplated by php code? How do you think anything is output? By either "ech= o" or ?> content <?php, or fwrite/file_put_contents
=
Without that, there is literally no purpose to php code (= or any code).


<= div>Include, include_once, require, and require_once have been around si= nce the beginning as the way to splice code files together. The behavior=  of these statements calls back to PHP's origin as a template = engine as they do things similar mechanisms like JavaScript's import do = not do (and for that matter, their equivalents in C# and Java). Their sc= ope behavior is very different from import mechanisms in other languages= , as they see the variables in the scope of the function they were invok= ed from or the global scope when called from there.  Their parsing = can be aborted early with a return.  They can return a value, which= is quite unusual to be honest. None of this is bad per se, but it is di= fferent and the question arises is it necessary.

How do you think javascript import works,= exactly? They load a file which returns a value via export.

There is nothing inherently wrong with requires/includ= es, it's literally required by every language via some mechanism or anot= her (C's include statements, go's go.mod file, javascripts import/packag= e.json, C#'s project config, etc). There's no magical thing here, just a= bstractions and different levels of it.


One artifact of their behavior that is= bad in my opinion is that they start from the standpoint of being text = or html files. 

<= div>Every single language starts with a text file... There's nothing inh= erently special about the bytes in any source code file and they only ha= ve meaning due to creating a parser that can make sense of the stream of= bytes. The fact that they also have meaning to humans is what makes it = source code and not object code/byte code.

If the included file has no PHP tags then the cont= ents get echoed out. If there are no output buffers running this can cau= se headers to be set and fun errors to be had. So they can't be used to = create files that can only echo explicitly (that is, a call to the echo = statement or the like).

For headers, this is largely up to the SAPI (the program that exec= utes the PHP code, eg, frankenphp, php-fpm, mod-cgi, roadrunner, etc) an= d the fact that most SAPIs want to be able to run existing code where de= velopers have certain expectations of behavior. FrankenPHP did a little = something different with the support of the 103 status code which isn't = supported in any other SAPI (AFAIK). The CLI sapi doesn't output any hea= ders whatsoever.

As far as PHP opening tags= go... I don't even notice it. They're there, just like the "package" de= claration on the top of every one of my Go files.


Fast forward a bit - PHP 5.3, an= d the introduction of namespaces were introduced to deal with the overlo= aded symbol tables. They are a bit a hotwire as (if I'm not mistaken, it= 's been a couple years since I read the discussion on it) they just quie= tly prepend the namespace string in front of the name of all new symbols= declared in the namespace for use elsewhere. As a result, PHP namespace= s don't do some of the things we see in the namespaces of other language= s (looking at Java and C# here). For example, privacy modifiers within a= namespace aren't a thing.

This would be nice to have ... maybe. But namespace have been a= round, what, 10-15 years? I think if someone wanted to "fix" it, it woul= d have been fixed by now.

=

Very quickly after PHP 5.3 released autoloaders show= ed up. At some point support for multiple autoloaders was added.  S= everal schema were added, PSR-4 won out, and composer showed up to lever= age this. Composer is based on NPM, even to the point where json is used= to configure it, and the composer.json file is fairly close to npm's pa= ckage.json file even now.  It's a userland solution, but to my know= ledge WordPress is the only widely used PHP application out there that d= oesn't use it directly (there is a Composer Wordpress project).

WordPress predates compose= r et. al., by more than 10 years (if you count the B2 code it was forked= from). Why would it use it? From working at Automattic (I left a couple= of years ago, and this is merely what I saw as an observer, I wasn't cl= osely involved with any of the open-source side), there was a bit of a p= ush to make it happen as it looked like Composer would be around for awh= ile, but then there was talk about an "official" loader/thing from php i= tself and I think they'd rather use that instead. When you have a projec= t that has literally been around decades, you don't change out your whol= e system on the whims of what is fashionable at the time; you either inn= ovate or wait and see what becomes standard. Composer has only been arou= nd 50% of the time WordPress has been around now; and it didn't start ou= t as immediately popular.

=
Before composer, and before namespaces there was PECL.  Compos= er has eclipsed it because PECL has the limitation of being server-wide.= It never really caught on in the age of virtual hosting with multiple P= HP sites running on one box. Today we have Docker, but that didn't help = PECL make a comeback because by the time docker deployment of PHP sites = became the norm composer had won out.  Also, composer library publi= shing is more permissive than PECL. I'll stop here lest this digress int= o a Composer v PECL discussion - suffice to say stabs a bringing code pa= ckages into PHP isn't a new idea, and a survey of what's been done befor= e, what was right about those attempts and what was wrong needs to be co= nsidered before adding yet another php package system into the mix.
<= /div>

I don't think PECL and= Composer have much in common... at all. Like they are not even comparab= le, and it is still the best way to install extensions (in fact, it is t= he only way in a docker container AFAIK) on a self-compiled php.

The main influence of composer a= nd autoloaders for preparing packages is that PHP has become far more Ob= ject Oriented than it was before.  Prior to PHP 5.3 object oriented= programming was a great option, but since autoloaders cannot bring in f= unctions (at least not directly, they can be cheated in by bundling them= in static classes which are all but namespaces) the whole ecosystem has= become heavily object oriented.
=
require/include still works fine, or using the "file" key= on the autoloader in composer.json.

I don't fi= nd most of these "problems" actually valid. There is some merit to the c= onclusions, but the premise feels shaky.

=E2=80=94 Rob
--0d104b6dd3b0487587ebce65fa8d7bfb--