Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124210 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 CFA161A009C for ; Thu, 4 Jul 2024 01:56:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1720058296; bh=m1wcbJZJvtVVrazKHshgutnF9jK9Wr7K9JpbJqakU7U=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=f309pNwV+lxIUOrTtjOEH5TJgvB0OzMgs7YgjwuGd2INn6wTkozmkXE3kafKhafiy YrSkHQPdqhk+7T35bW11BlrUlkUa9CRdsrBTHtZbyN8h5qFTgDwJkYggISLTKXV/LI 5T5Kmhvdk1l8J/xmH8V/Oz89akYOffdWQ1C+4pvcdumLWq21ahVIbKhiJAihsy6Mkk 2fp3eP13GjkKvlZcKH+Mg5q4oAGTv19r2YHNYFGdYrZAQdaKH8rgfmvRcHktIaClMp +kSfEhR0OUhybhGCl4BLnpO7fCf8gSaCmtXbm4IJ8wUM6RzYzH0LkVB3pbdRiORCqp f01LI/HInZMyg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D5FD918004A for ; Thu, 4 Jul 2024 01:58:15 +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.8 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DMARC_MISSING,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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-yw1-f171.google.com (mail-yw1-f171.google.com [209.85.128.171]) (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 01:58:15 +0000 (UTC) Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-651815069f8so10970807b3.1 for ; Wed, 03 Jul 2024 18:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20230601.gappssmtp.com; s=20230601; t=1720058212; x=1720663012; darn=lists.php.net; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=Hz6GWcOw/LXRVbLO/irP9AHGl8zxOz+0fP/hTo9nlD0=; b=wdGdWxj9+49ItxSQ/e2xRe35dtAP2gO/QPUZJdgM8fcx/r5lxxrEgKVPtQr+YAfa11 D77hligIoSa9uEgZRlClOSlk2JAzuQ0OurDEnY5xZ8VsWgxXRUEJI+UsG4rcM7LA9tJP OLaw5kbV8RrxHHMnm/gOBcvC5Wz+hRMM33l1W+hQNxw4hvF3T2OwdvmAiHm14hZ+RTUz cNc2sVmi/oyEkN8Rb3vTK7NhLVC1kXAnCW7xgbCAD79m9YSoujUT/t98xdqrmdxXOv2L 5g6UgS9ixXQrBlm/jjnoKZ0wklSxqQMFXflag9+OONtYoL7TjZA0JMAP4bwOChEBxqqy Gd8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720058212; x=1720663012; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Hz6GWcOw/LXRVbLO/irP9AHGl8zxOz+0fP/hTo9nlD0=; b=tDVtSpVfMR1w3AruP5D1Xd8QN64VwjqcDj/7k6z512JOzNMQPtcKun6IdHW+BSg9GG Mj+5+ly8tPcvHEJ/QY+/dkgUjKXYj3RrTrANPEmPjUArg40MZMH0h3HK1zj1pFXTHqNm aGaUxovphhVOkoXCrpuWOMBC8lXKAjVC3mvkRrba21UO/WT3vd1Qp7IF9sUZnxu/ixYG YmKCXzFmPUmK9F1YwtuHz2Utx5xlqFC2mNeYI9e96E1lsoa7F7z5+RWQV0B9B4DmgLVL EPCoLTI5BCtlV8Nk3HeU8nLKPrFzLEQyL8mikpGpdr/zM4gGjzTr6qp8wh6wvvvzvVFG daZg== X-Gm-Message-State: AOJu0YyOOWJA6iWUDKhqNGa3JOzS6Cn0w958yfjdPp61QnjCsB+kraJX K92CrrFlbQMBL9FYI1JImPu8TJpZ5B9AHqQJYEBP82MuIpa/IzOp6dTcv3aWpvidn4DrSMxC2ka 3Nvw= X-Google-Smtp-Source: AGHT+IGCHFQ0ILdX83OVE/EIobOz9HzNoSRjjdl6PTRiI9jWnp5O7lfyxFKpIbvd7RN70cKu4A2meQ== X-Received: by 2002:a05:690c:a88:b0:643:9ee0:25e0 with SMTP id 00721157ae682-652f6bd52ecmr184307b3.22.1720058212534; Wed, 03 Jul 2024 18:56:52 -0700 (PDT) Received: from smtpclient.apple (c-98-252-216-111.hsd1.ga.comcast.net. [98.252.216.111]) by smtp.gmail.com with ESMTPSA id 00721157ae682-64a9ba5a1fesm23373927b3.101.2024.07.03.18.56.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2024 18:56:52 -0700 (PDT) Message-ID: <7B633CC7-C768-4852-A4D0-B252A04F7DE1@newclarity.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_B82A6AC4-3855-499E-B0EC-797F06723D1D" Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Subject: Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV) Date: Wed, 3 Jul 2024 21:56:51 -0400 In-Reply-To: Cc: PHP internals To: Michael Morris References: <09559430-4477-4516-8D78-6F4071E1AA6C@newclarity.net> <0182F3D6-F464-477F-9029-A2D0A8B50C71@koalephant.com> <1AFD7AAE-8BEA-460D-88A8-15BB3D30A775@koalephant.com> X-Mailer: Apple Mail (2.3696.120.41.1.8) From: mike@newclarity.net (Mike Schinkel) --Apple-Mail=_B82A6AC4-3855-499E-B0EC-797F06723D1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 3, 2024, at 8:16 PM, Michael Morris wrote: > Can PHP support multiple packages without rewriting the whole engine? = I think so, but it isn't trivial, and the side effects need to be = cordoned off so that those who need this complexity can have it while = the beginning and intermediate coders can ignore it just like they = ignore strict comparison operators and strict typing unless a library = they are trying to use foists it on them. >=20 > This is why I advocate a new keyword for this - import.=20 There are ~6300 uses of the keyword `import` on GitHub: =20 = 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. For this proposal, would one of these not be acceptable instead = (assuming that the compiler could handle `import` in this way w/o it = being a new reserved word)?: ``` include "file.php" as import use import "file.php" ``` > 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 or 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 = and then at the end of loading the file PHP would flush those symbols = just like how (I think?) JavaScript imports work (I am ignoring the = complexity closures add to simplify our discussion here.) 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? 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. > Now we have \B\foo(); 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 doesn't solve the multiple extensions = wanting to use the new 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? How does the PP2ER Connector use 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 = classes have private and protected properties that are simple not = composable, and especially not across versions. 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? > So we have to call out the version in code, like so. >=20 > import 'file.php v1.0.0'; Where will PHP be able to get the version number in a performant manner, = remembering that the problem to be solved is dependencies of = dependencies so you cannot rely on a strict directory structure with = version numbers unless a non-PSR4 autoloader format is introduced and = widely adopted? Will packages need to ship `composer.lock` and developers deploy them? = Will that be performant and secure enough? What about libraries and packages that do not use Composer? How will = WordPress handle this with plugin dependencies? -Mike --Apple-Mail=_B82A6AC4-3855-499E-B0EC-797F06723D1D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Jul 3, 2024, at 8:16 PM, Michael Morris <tendoaki@gmail.com> = wrote:
Can PHP support multiple packages without rewriting the whole = engine?  I think so, but it isn't trivial, and the side effects = need to be cordoned off so that those who need this complexity can have = it while the beginning and intermediate coders can ignore it just like = they ignore strict comparison operators and strict typing unless a = library they are trying to use foists it on them.
This is why I advocate a new keyword = for this - import. 

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


That's a lot of BC breakage for some = people.

For this proposal, would one = of these not be acceptable instead (assuming that the = compiler could handle `import` in this way w/o it being a new reserved = word)?:

```
include = "file.php" as import
use import = "file.php"
```

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 or 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 and then at the = end of loading the file PHP would flush those symbols just like how (I think?) JavaScript imports work (I am = ignoring the complexity closures add to simplify our discussion = here.)

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?

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.

Now we have = \B\foo();  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 doesn't solve the multiple extensions wanting to = use the new 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?

How does the PP2ER Connector use 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 = classes have private and protected properties that are simple not = composable, and especially not across versions.

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?

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, remembering that the problem to be solved is = dependencies of dependencies so you cannot rely on a strict directory = structure with version numbers unless a non-PSR4 autoloader format is = introduced and widely adopted?

Will = packages need to ship `composer.lock` and developers deploy them? Will = that be performant and secure enough?

What about libraries and packages that do not use = Composer?  How will WordPress handle this with plugin = dependencies?

-Mike

= --Apple-Mail=_B82A6AC4-3855-499E-B0EC-797F06723D1D--