Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124211 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 EFA8F1A009C for ; Thu, 4 Jul 2024 02:31:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1720060367; bh=WfvJbtcLb5chPnAWo1S3/uLdFw5ymChUcIle0Rtmmks=; h=References:In-Reply-To:From:Date:Subject:To:From; b=dYs9zp6CmdR06P4HarKmmzdi1rOI5I1+Nlv5yWKa+gGUqqDIFDX9TUmhUVWHl97Qc xnabsg/psaE0qSKxEHC2e7jaM4V+nk8vKNCS4uUpvRBWPerbvz/dW/bQioW3aIwKYV guwzDYBsX24iCkpfSIXcTDrx9qphKVC9WPHy+so7f1gwOIHpqkKB9Gvxa7yaXm+Y6e o5EHZHF71Be9Ytq81NV+zCE7gR3D3i6yygjPZvgJis9e7B6JQxMvolQvsitqOwm+xR 0c1mT63i5+zq7SRUObGnYRjVNHDPivRYWsZoQNrZZhvUmN3Bb31lI8UbbN8jjR45Cn DMQib2gOiykHw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D43DD18004A for ; Thu, 4 Jul 2024 02:32:46 +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-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.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, 4 Jul 2024 02:32:46 +0000 (UTC) Received: by mail-qv1-f51.google.com with SMTP id 6a1803df08f44-6b2c95b6c5aso872136d6.2 for ; Wed, 03 Jul 2024 19:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720060283; x=1720665083; 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=av/skX06U32evGcHofBN6jdU5VAyPP/ByAk1hI01Jj0=; b=eJi2xko6GahtfuEbwr/ntXBv4ZL8uI/PEgHVugl72GcZchFRb3e1cg48I44ipuxJxP 7vcrlI2owllQYF1PFHis3+HZLal6HGuQAJecB5JOkkHnd8DJlvsCCogOG4FgdKzJpLFz 0QG5oSJLOMYEtp+aNYKSwkIHmRs+U4meo7vl6zehCDnMT6zv7qQ1d5xMZOiQEiJQDHGF BOCQlwAZUYgRyGTkXOfAfjaBPP4wLHfFjn55rD2li/yJ7gNKoquLoA7DNSvq/2rCtvHx Xd55+BNmPUOlPVelwv4pJHvu+sV52J9u0lM1LC6c0HOj8d+l3YUk78MvTSSwXXtzvawy 1w5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720060283; x=1720665083; 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=av/skX06U32evGcHofBN6jdU5VAyPP/ByAk1hI01Jj0=; b=uvsvYkhlXbLjA9qM26iqu1XkXhHL+wZVwXXp3TvxddRivlU44U0G3ssiSgQ9MASj/f u0XDuhkrPA+4KHI8k4FtMCegjYaf4TUTN4RDA8IZhXHzy23M3gQGAIVhvmDN3wD/+2cF Mg3uR04K2Kxi7bfUqaYj+bRG8fbTBfolBhe9qgRzWiyxOGNKvt6a6xOf4LywzuIZBzSc j5kNBSHOvRkXkpepqI1D3zTofLW+bom3z4ytH0n19/Y0PBEoMe0j4C5Eifv7Nip3Gz7d uGnw2c9I3CuAHiES+g86ImhautXSz1IQjqBMHzeG2J9srkgJDBfLUjEvdOd2PQwsuisC 2RSA== X-Gm-Message-State: AOJu0YzraMm051VE317jXvvvWad/TempBJA0F/Evh0CHzsugkJsW8y4A qYo+2hPxF3RdIzS1MwnEWbtrm7xzImgGqVHUaGQoMPD1nzaZWiyscNGffZHaYwAyUE71vsmVzcb CcPa1b/FtpNTSoSXVlt4XCD0bW7SMhg== X-Google-Smtp-Source: AGHT+IEzun4p3JnALg46U/i9ZlBPbi81cCqlGVaRe6eebcViLPDLxSlLLceUj2dfwczee2EedUMTDdvTV8Argl2PVoE= X-Received: by 2002:a05:6214:2a46:b0:6b4:ff5c:e5dc with SMTP id 6a1803df08f44-6b5ecfaea67mr3008496d6.29.1720060283346; Wed, 03 Jul 2024 19:31:23 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: <09559430-4477-4516-8D78-6F4071E1AA6C@newclarity.net> <0182F3D6-F464-477F-9029-A2D0A8B50C71@koalephant.com> <1AFD7AAE-8BEA-460D-88A8-15BB3D30A775@koalephant.com> <7B633CC7-C768-4852-A4D0-B252A04F7DE1@newclarity.net> In-Reply-To: <7B633CC7-C768-4852-A4D0-B252A04F7DE1@newclarity.net> Date: Wed, 3 Jul 2024 22:31:11 -0400 Message-ID: Subject: Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV) To: PHP internals Content-Type: multipart/alternative; boundary="0000000000002e6740061c62bea6" From: tendoaki@gmail.com (Michael Morris) --0000000000002e6740061c62bea6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 3, 2024 at 9:56=E2=80=AFPM Mike Schinkel = wrote: > > There are ~6300 uses of the keyword `import` on GitHub: > > > https://github.com/search?q=3Dimport+language%3APHP+symbol%3A%2F%5Eimport= %24%2F&type=3Dcode > > > That's a lot of BC breakage for some people. > > No worse than PHP 7's keyword introductions. > Import's behavior is most similar to require_once, but it doesn't have to > be the same. Since it is a new entrypoint into the engine the way the > engine considers the code can be different - whether slightly different o= r > radically different is a debate for another time. I'm going to stick with > only those changes that make sense in the context of package links. > > > When you first proposed modules I was understood *(wrongly?)* that you > were proposing imports to be a statement that imported into file scope an= d > then at the end of loading the file PHP would flush those symbols just li= ke > how *(I think?)* JavaScript imports work *(I am ignoring the complexity > closures add to simplify our discussion here.)* > That was the first iteration, yes. I am adjusting to the feedback on the list. JavaScript does imports the way it does because of how files scope, and how the module system itself scopes, which isn't readily retrofitted onto PHP. Also, at the time I was toying around with the format and had yet to hit upon the situation where it could be useful, that being versioned files. > This sounds like you are saying `import` would *(*instead*?)* be dynamic > like `include*` and `require*` and any symbols loaded with `import` would > continue their lifetime until the program is finished or the page is > loaded, depending on how the program is run? > Yes, because that is how PHP itself does work under the hood, at least for php file includes. How it would go about doing this when resolving .so or .dll extensions is another matter. Does it have to be this way? That's the hint I've gotten from the feedback but only a core contributor with experience working on the engine could say for sure. > I ask because when I was envisioning page scope being added to PHP I was > also envisioning that PHP could perform more optimizations if the new > symbols only affected the currently loaded page. If you are proposing > beyond-page lifetime then that precludes this optimizations which is not = a > deal killer but is a disappointment. > Whether the optimizations affect the file on load depends on what's being optimized to be honest. There is still an opportunity here. > Now we have \B\foo(); This makes it relatively easy to have two differen= t > versions of the package running since in our own code we can always > reference the foo in the B namespace. But while that allows limited packa= ge > versioning, it doesn't solve the multiple extensions wanting to use the n= ew > stuff problem outlined above. > > > Consider the following parts of an application: > > 1. Bespoke app > 2. "Enterprise Reports" library > 3. Twig v3 used by "Enterprise Reports" > 4. "ProductsPro" library > 5. Twig v4 used by "ProductsPro" > 6. "PP2ER Connector" library > > Given your scenario I guess you assume Enterprise Reports would import > Twig v3 as maybe `ER\Twig` and ProductsPro would import Twig v4 as maybe > `PP\Twig`, right? > Correct. > > How does the PP2ER Connector use Twig? > Depends on which one it wishes to use, \ER\Twig or \PP\Twig > Does it create it own `PP2ER\Twig`? What if the connector needs to use > the `ER\Twig\Environment` from ProductsPro with the > `Twig\Loader\FilesystemLoader` from Enterprise Reports where those classe= s > have private and protected properties that are simple not composable, and > especially not across versions. > I've never seen cross version mixing like you're describing so I didn't take it into account. That said, the extant copies of those classes will be variables, and hopefully not global variables. > > Or what it he app itself needs to use the functionality of both in a way > that requires access to `private` and/or `protected` property values or > methods across the two versions? > That isn't in scope for this discussion. The whole point of private and protected scope modifiers is to restrict access by outside code. Breaking through that can be done with the Reflection API in some cases, but it isn't easy. > > So we have to call out the version in code, like so. > > import 'file.php v1.0.0'; > > > Where will PHP be able to get the version number in a performant manner? > A question for another day. I'm not going to touch on it yet as I want feedback on the rest of what I've written in this iteration first and, honestly, I want to mull it over in my head a little more. It may be that the code doesn't have the version number but the package declaration file does. There definitely would be advantages to that, but it may still be desirable to have the version called out in the import statement in code. --0000000000002e6740061c62bea6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 3, 2024 at 9:56=E2=80=AFP= M Mike Schinkel <mike@newclarity.= net> wrote:

There= are ~6300 uses of the keyword `import` on GitHub: =C2=A0

No worse tha= n PHP 7's keyword introductions.
=C2=A0
Import's beh= avior is most similar to require_once, but it doesn't have to be the sa= me.=C2=A0 Since it is a new entrypoint into the engine the way the engine c= onsiders the code can be different - whether slightly different or radicall= y different is a debate for another time. I'm going to stick with only = those changes that make sense in the context of package links.
<= /div>

When you first proposed modules I was= understood=C2=A0(wrongly?) that you were proposing imports to be a = statement that imported into file scope and then at the end of loading the = file PHP would flush those symbols just like how (I think?) JavaScri= pt imports work (I am ignoring the complexity closures add to simplify o= ur discussion here.)

= That was the first iteration, yes.=C2=A0 I am adjusting to the feedback on = the list.=C2=A0 JavaScript does imports the way it does because of how file= s scope, and how the module system itself scopes, which isn't readily r= etrofitted onto PHP. Also, at the time I was toying around with the format = and had yet to hit upon the situation where it could be useful, that being = versioned files.
=C2=A0
This soun= ds like you are saying `import` would (instead?)=C2=A0be dyna= mic like `include*` and `require*` and any symbols loaded with `import` wou= ld continue their lifetime until the program is finished or the page is loa= ded, depending on how the program is run?

Yes, because that is how PHP itself does work under the ho= od, at least for php file includes. How it would go about doing this when r= esolving .so or .dll extensions is another matter.=C2=A0 Does it have to be= this way? That's the hint I've gotten from the feedback but only a= core contributor with experience working on the engine could say for sure.=
=C2=A0
I ask because when I was = envisioning page scope being added to PHP I was also envisioning that PHP c= ould perform more optimizations if the new symbols only affected the curren= tly loaded page. If you are proposing beyond-page lifetime then that preclu= des this optimizations which is not a deal killer but is a disappointment.<= br>

Whether the optimizat= ions affect the file on load depends on what's being optimized to be ho= nest. There is still an opportunity here.
=C2=A0
Now we have \B\f= oo();=C2=A0 This makes it relatively easy to have two different versions of= the package running since in our own code we can always reference the foo = in the B namespace. But while that allows limited package versioning, it do= esn't solve the multiple extensions wanting to use the new stuff proble= m outlined above.

Consider the = following parts of an application:

1. Bespoke app<= /div>
2. "Enterprise Reports" library
3. Twig v3 us= ed by "Enterprise Reports"
4. "ProductsPro" l= ibrary
5. Twig v4 used by "ProductsPro"
6. &q= uot;PP2ER Connector" library

Given your scena= rio I guess you assume Enterprise Reports would import Twig v3 as maybe `ER= \Twig` and ProductsPro would import Twig v4 as maybe `PP\Twig`, right?

Correct.
=C2=A0

How does the PP2ER Connector us= e Twig? =C2=A0

Depends on= which one it wishes to use, \ER\Twig or \PP\Twig
=C2=A0
Does it create it own `PP2ER\Twig`?=C2=A0 What if t= he connector needs to use the `ER\Twig\Environment` from ProductsPro with t= he `Twig\Loader\FilesystemLoader` from Enterprise Reports where those class= es have private and protected properties that are simple not composable, an= d especially not across versions.

I've never seen cross version mixing like you're describin= g so I didn't take it into account. That said, the extant copies of tho= se classes will be variables, and hopefully not global variables.
=C2=A0

Or what it he app = itself needs to use the functionality of both in a way that requires access= to `private` and/or `protected` property values or methods across the two = versions?

That isn't = in scope for this discussion. The whole point of private and protected scop= e modifiers is to restrict access by outside code. Breaking through that ca= n be done with the Reflection API in some cases, but it isn't easy.
=C2=A0

So we have to call out the version in code, like so.

=C2=A0 import 'file.php v1.0.0';

Where will PHP be able to get the version nu= mber in a performant manner?

<= div>A question for another day. I'm not going to touch on it yet as I w= ant feedback on the rest of what I've written in this iteration first a= nd, honestly, I want to mull it over in my head a little more. It may be th= at the code doesn't have the version number but the package declaration= file does. There definitely would be advantages to that, but it may still = be desirable to have the version called out in the import statement in code= .

=C2=A0
--0000000000002e6740061c62bea6--