Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124037 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 5E02D1A009C for ; Sat, 29 Jun 2024 15:10:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719673895; bh=Tu8jXlgIcplnASJW1CJ2VGdOqdjwgNwpihI6bP0q+cA=; h=References:In-Reply-To:From:Date:Subject:To:From; b=VFufZZjhnq9qxM2hrn94qLbzCeJLtFAeKD3ot8j2F3wGmGKznxclkbF7h+QlArwxH D6QIov1TgFWHcPsfdJXYLaQUMK7NiVyHa2Q5OV4FxMyy5Ox8CdtK915OGVZU27sYbD AA/B0ZQ1/TQrLP41Qg0aY766FbaJgiU95QNidrH3yX2eP8Is+sy3AL/EpEG/dzab5f Y4LrzTp803jkyrXtnTGl3kEKxaQtXkjbip1Kcfm8ZfDc7aSO38NuOG8wUJo3cJIi/p uoyjw+vlBmFNLcIMDGoxxvSkia56yyZToJFkTEZZum9DLqsoNdUR+J5nL5v0uLzvWM J+Lj1SeOpt3Ig== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 4E3C21807F7 for ; Sat, 29 Jun 2024 15:11: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-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) (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 ; Sat, 29 Jun 2024 15:11:33 +0000 (UTC) Received: by mail-qk1-f177.google.com with SMTP id af79cd13be357-79c054b65d4so97911285a.1 for ; Sat, 29 Jun 2024 08:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719673813; x=1720278613; 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=NS7b1DB2mmnYld91eYAcqLB3fQPQkSdiBYmfmwd+86c=; b=HGWsGc4cfH+sSS8JRdcUijhr7hBzJHljOqbQkGRKcBpCD/V/fm3W7sqOyR9BEw+XYJ cAobGJW6GLLzPxsfscchds2DlxnS0pbfbVCo1mSM1j+ktr5uJa5uFovhDPIUP5dbKtp3 30riN/hlIDCncimyiDPskqfSWnfLJlc6Z+PtqWEf6DW+Im8N/Z9PAnBdAi3dKMpDXhOH wwV1+Gt3IpWkdcWA+ePrwpLO5Sk+Nh3EvBSqXETRuH9CZydzdOr52J34Redyx92S5/qR C0AKsTo45nmwY2YkxaDyPrCPu4DQuIysYre/qTgR7Z0q5WshIRKSAsAW+jmFqaCwTMy4 i8Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719673813; x=1720278613; 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=NS7b1DB2mmnYld91eYAcqLB3fQPQkSdiBYmfmwd+86c=; b=RouSzN8tc94Se4U2wnRiWz/Xh7LRRO7oKrM10pflygOWbsStHVOAt8f+x4npCJHFWi KAPA/kjZDeAQTC8QW4woq7VsUNdt8nUPzoqdmVJgzpybLVbBfj4/4brDEz/QsXrAyzBC Jr+pVrnsbscqeYEPmW7/AKBllKA5VlxqugWuPEndL3PSY7xC/L77neuhdMiSxGPQL9IG KOz74nhZXZvdJF2M/ygu1UasliklJmAu5EaTaiwVxWM1wBPdxo/tBczDCQIHnp3g03oh HyZx4Oq85P/dEsRQtYhwzXLZTeCyE8dbjjFgHO0cn+r/y7y+bLyfxdcOL+ooNi4SrGVs gj5w== X-Gm-Message-State: AOJu0YwH2DYYtNcf87ocQMU+6mVv8k9r6FADKgyMx97NGgM4GJyKHHNa EXsgXEAkA0x6hyKqrZ3SFgFR7YxO39aZttB2Z5ov4nYnYFy2YIi0gAGKCRVpNKRS5TNsARLQ0dK 0uISTUnR2oiQSQz9JjZ2iIK++1+VwRg== X-Google-Smtp-Source: AGHT+IGSN9r+DAVPPWSWK1ahmAg5aTFOj0iZsN/YVQoPcUlQqQEEdi7esSrqebmGKEwPKtL2o84L25mI5PWg8Rwg3+Q= X-Received: by 2002:a05:6214:48b:b0:6b2:b2a3:67ce with SMTP id 6a1803df08f44-6b5b716de7amr14325876d6.51.1719673813050; Sat, 29 Jun 2024 08:10:13 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: <1917CF7C-26D8-4DBE-B05C-5AA650AC6C9F@rwec.co.uk> <551cd5b0-1c00-4818-a9ca-97f6b7e8c3dc@app.fastmail.com> <4c8ec1e7-d126-45f4-9260-ae1d90bcfe8c@app.fastmail.com> In-Reply-To: Date: Sat, 29 Jun 2024 11:10:00 -0400 Message-ID: Subject: Fwd: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript To: PHP internals Content-Type: multipart/alternative; boundary="000000000000c1ad32061c08c22e" From: tendoaki@gmail.com (Michael Morris) --000000000000c1ad32061c08c22e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jun 29, 2024 at 3:52=E2=80=AFAM Rob Landers wro= te: > I don't think that is correct... > Correct or not it's irrelevant trivia. While this looks good on paper, you're going to have to standardize how > packages are accessed (API calls, etc) so they can be used in this file, = or > literally anyone who wants to add a competing registry will have to creat= e > an RFC to allow accessing their own registry, which is a ton of politics > for something that is strictly technical -- not to mention a bunch of > if-this-registry-do-that type statements scattered throughout the code, > which makes it harder to maintain. > While this is a fair point, it's a discussion of trees while we are talking about the forest. At this early stage of sketching out this system what we are concerned with is how the registry is set and whether multiples can be set. Once that's hashed out the details of how registries work - authentication and all that can be contemplated. > SAPIs are the programs that parse ALL php code and return it to the serve= r > (ie, nginx, apache, caddy, etc) to be displayed. > I mis-spoke. What I mean is these files cannot be *directly* invoked. A normal php file must load first, then the phm file, even if the php file is a mere one liner that imports the module. > In other news, I'm not a fan of how many times I have to write "twig" jus= t > to get Twig in the current file. The module already registers a namespace= , > why can't the use-statement implicitly import the module? > Because that's not how PHP works? In this pass I took the stance of not ditching namespaces and instead incorporating them directly into this module system. In any event, those namespaces will continue to exist outside the module system for years. The idea of ditching namespaces within the modules was met with immediate resistance. > > In real life, my code is going to be in a module/framework and I'm going > to need to render it there. This example of exporting a dependency also > kinda breaks encapsulation principles, and even though it is an example, > things like this end up in documentation of a feature and cause all kinds > of bad practices (like Symfony and anemic objects). > > I actually thought about that after typing this and as I was going to sleep. How this should work is the symbols imported by a module are only visible in that module. If two modules share a dependency the resolution must allow them to use different versions, especially if they are different major versions as there might be a BC break in their shared dependency which is the reason one module uses the older version > One of the first things I do in a composer.json file is remove polyfills > through the replace key. It's unnecessary, annoys me in my IDE with havin= g > multiple classes of the same name, and hides the fact that I should > probably install an extension for better performance. How do we do that > with this new setup? > Go has replace directives in go.mod which you're welcome to look into, but exploring that level of detail is premature. > In fact, it is worth pointing out that how would this system work with > polyfills in-general? > Not yet it isn't. > > So ... if we want to round, we have to use `import @math` and then we can > call the global round() function? > No one said anything about removing php.ini extension directives to globally install extensions. > Or if we want to use DateTimeImmutable we have to add `import @date`? Tha= t > seems like a step in the wrong direction since most people don't even kno= w > that most (if not all) global library functions come from extensions -- a= nd > virtually nobody knows the name of each extension and what functions they > have. Also, installing extensions is not 100% straightforward as some > environments need to use pecl, some need to use OS package managers. > I don't understand this contrarian hostility. As you say, the current system isn't straightforward. I'm proposing something that is straightforward and your reaction is to go on about how not straightforward the current system like it is highly relevant to the proposal. It isn't. What is relevant is this - composer packages that require specific extensions aren't as portable as those without such requirements as their incorporation requires jumping through extra hoops. Wouldn't it just be better if a module could call out its extension dependencies and have PHP be able to get them installed WITHOUT asking the user to fire up PECL or modify the php.ini file? --000000000000c1ad32061c08c22e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, Jun 29, 2024 at 3:52=E2=80=AFAM Rob Landers <rob@bottle= d.codes> wrote:
I don't think that = is correct...

Correct or= not it's irrelevant trivia.

While this looks good on paper, you&#= 39;re going to have to standardize how packages are accessed (API calls, et= c) so they can be used in this file, or literally anyone who wants to add a= competing registry will have to create an RFC to allow accessing their own= registry, which is a ton of politics for something that is strictly techni= cal -- not to mention a bunch of if-this-registry-do-that type statements s= cattered throughout the code, which makes it harder to maintain.
<= /div>

While this is a fair point, it's = a discussion of trees while we are talking about the forest. At this early = stage of sketching out this system what we are concerned with is how the re= gistry is set and whether multiples can be set.=C2=A0 Once that's hashe= d out the details of how registries work - authentication and all that can = be contemplated.
=C2=A0
SAPIs are the programs that parse ALL ph= p code and return it to the server (ie, nginx, apache, caddy, etc) to be di= splayed.

I mis-spoke. What = I mean is these files cannot be *directly* invoked.=C2=A0 A normal php file= must load first, then the phm file, even if the php file is a mere one lin= er that imports the module.

=C2=A0
In other news, I'm no= t a fan of how many times I have to write "twig" just to get Twig= in the current file. The module already registers a namespace, why can'= ;t the use-statement implicitly import the module?

Because that's not how PHP works? In this pass = I took the stance of not ditching namespaces and instead incorporating them= directly into this module system. In any event, those namespaces will cont= inue to exist outside the module system for years.=C2=A0 The idea of ditchi= ng namespaces within the modules was met with immediate resistance.
=C2=A0
=

In real life, my code is going to be in a module/= framework and I'm going to need to render it there. This example of exp= orting a dependency also kinda breaks encapsulation principles, and even th= ough it is an example, things like this end up in documentation of a featur= e and cause all kinds of bad practices (like Symfony and anemic objects).


I actually though= t about that after typing this and as I was going to sleep. How this should= work is the symbols imported by a module are only visible in that module. = If two modules share a dependency the resolution must allow them to use dif= ferent versions, especially if they are different major versions as there m= ight be a BC break in their shared dependency which is the reason one modul= e uses the older version
=C2=A0
One of the first things I do in a composer.= json file is remove polyfills through the replace key. It's unnecessary= , annoys me in my IDE with having multiple classes of the same name, and hi= des the fact that I should probably install an extension for better perform= ance. How do we do that with this new setup?

Go has replace directives in go.mod which you're welc= ome to look into, but exploring that level of detail is premature.

=C2=A0
In fact, it is worth pointing out that how would t= his system work with polyfills in-general?=C2=A0

Not yet it isn't.
=C2=A0

So ... if= we want to round, we have to use `import @math` and then we can call the g= lobal round() function?

No one= said anything about removing php.ini extension directives to globally inst= all extensions.

=C2=A0
Or if we want to use DateTimeImmutabl= e we have to add `import @date`? That seems like a step in the wrong direct= ion since most people don't even know that most (if not all) global lib= rary functions come from extensions -- and virtually nobody knows the name = of each extension and what functions they have. Also, installing extensions= is not 100% straightforward as some environments need to use pecl, some ne= ed to use OS package managers.

= I don't understand this contrarian hostility. As you say, the current s= ystem isn't straightforward.=C2=A0 I'm proposing something that is = straightforward and your reaction is to go on about how not straightforward= the current system like=C2=A0it is highly relevant to the proposal.=C2=A0 = It isn't.=C2=A0 What is relevant is this - composer packages that requi= re specific extensions aren't as portable as those without such require= ments as their incorporation requires jumping through extra hoops. Wouldn&#= 39;t it just be better if a module could call out its extension dependencie= s and have PHP be able to get them installed WITHOUT asking the user to fir= e up PECL or modify the php.ini file?
=C2=A0
--000000000000c1ad32061c08c22e--