Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124385 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 A074F1A00B7 for ; Thu, 11 Jul 2024 11:27:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1720697307; bh=yAC9DShdd9rQDtHj9hs/QnnTQGi5KCvCYWe5YYNi6OE=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=hB63dAN/awFd+QdJkOtZ91lazsBhpROwAQwE5fLj8637t6dsUxu4eWzdm6R0UVJ4F Cq+y88j/3mDSNyRq57AzwW4CpfUaQM+TtKKKrFvLhdz4/AH/flUDXTed7k/dijOwfD 4qXabSVWthcOvGaFjfeC/d8j2/ScLOGAYzWbqG77zhpJl6yFWl+p4RmkajTraVXXB3 FPY3fVaXPkuJJJjNKI7rPgQY6HbXHjprygCO2fTZWuMGuPh38z1Os+Yq+zr2shDfnH PCKE4N6WHb+LrfDcDpX+SxqzNUDD8QFIAURLaUYphh3zs7xDjNl5EZO94Fg3Rlw1gZ Xh7BwIsH2naKw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 80B27180086 for ; Thu, 11 Jul 2024 11:28:26 +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 autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) (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, 11 Jul 2024 11:28:25 +0000 (UTC) Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-64d408a5d01so7046597b3.1 for ; Thu, 11 Jul 2024 04:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20230601.gappssmtp.com; s=20230601; t=1720697219; x=1721302019; 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=x0V3UyjOkuF2Tas8QvPcASXRdKGNQB3gSGh3SzBAriY=; b=dbNxDme5nPcWcr8HtCssZN0YS+pSoLJOxUAyq3ZqwxnnKYM3bjEZcYiX9Lio43jnuP hYJHuOSlnDPmjelMrALUHyG+NnhZMMbjuh8alWmre+E4Bd/vlv7GOiDIRH/otTS648cj b4uYVA1Qz8TPYXxyFHqhVviRvMZx8FetL4V8ueGlle8Mc4azsUEzmnpjZPZOUaUazmge FAncR03EwghORrSSz4iVJ82ACong1LNlgSBhN2TnwhsPMYTR9snXXDBXU4obAJlOpkMw GdTby3oSp9zt8W6DUGAnBOWZEYDi2Pmg3Jw80Oi3iS+6jnDy4qsUVM+ucurl17fsTd5i h0Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720697219; x=1721302019; 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=x0V3UyjOkuF2Tas8QvPcASXRdKGNQB3gSGh3SzBAriY=; b=XM+mK4PHwr65MZxvjy46S5dBaaQFhZ1YyB3l/KPGPLLtt1NIElym85LAtYpYsrRTC5 m/HYdr1oFt9V82f90OnFqo+r+wOEvoxacANiZjvb4b+UwgcP+fRzy9j4OsFpu5zf1v5f 3ZyUIZGre3H7f7t/49QlOn0i+Sh4OmnIPpcCRoDmhgloWD90oHVDEjTtbjAqpXU7x48w LHPE0ZX9JByvmwtRrQKZxr7x8wOd+k377RH1guCpqNO9uKQ4SSoOMAAvKgvxjQ8Imn6j kLY0BgXTST/1MtZ4YXAMMZXFCFHDWzm36FATDaB3mOqByJBlQNXsgQFXfrlk2S4S8wqT a33w== X-Gm-Message-State: AOJu0Yxe/peDObyzbjN5twyNT2tia7htPvJUXVTQVN98gqRijAUomZGa wrn/MWl33FhnjtNEbMi86UAmhMD3EK7OpF8svHena9FfelnGJdcrut9Zaj/iaKI= X-Google-Smtp-Source: AGHT+IF983pQG3swcfSskv2+3DdiDY7pagXZLr0j2w4ed5D/4qd8hBLA3dOjX5OfX63eEez48hdbnw== X-Received: by 2002:a81:a606:0:b0:651:a00f:6971 with SMTP id 00721157ae682-658f02f4ce7mr90746427b3.42.1720697218601; Thu, 11 Jul 2024 04:26:58 -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-658e521c7bcsm10419207b3.65.2024.07.11.04.26.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2024 04:26:57 -0700 (PDT) Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_BD693EF5-E8F4-40BF-BCD4-2C1C9FC2E61C" 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: Thu, 11 Jul 2024 07:26:56 -0400 In-Reply-To: <3c09786f-705d-4601-91a0-d2498304bbd7@app.fastmail.com> Cc: php internals To: "Rowan Tommins [IMSoP]" , Larry Garfield 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> <0E11F373-99DC-496E-9BBC-2F8688B9F66A@newclarity.net> <4F720A7A-B7DD-4B31-B0C9-6907419B53A5@newclarity.net> <7b40e925-d642-4cf4-83f8-f903a9964362@app.fastmail.com> <3c09786f-705d-4601-91a0-d2498304bbd7@app.fastmail.com> X-Mailer: Apple Mail (2.3696.120.41.1.8) From: mike@newclarity.net (Mike Schinkel) --Apple-Mail=_BD693EF5-E8F4-40BF-BCD4-2C1C9FC2E61C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Preface: I am going to bow out of this conversation now (unless pulled = back in) and come back after 8.4 settles. In the mean time I'll be working on two proof-of-concepts. One is a = totally userland PoC for packages being able to load same-named symbols, = and the other will be working out how to use multiple symbol tables in = PHP core. And as I have never modified php-src before, that is going to = take some learning. However, below are responses to Rowan and Larry. > On Jul 10, 2024, at 8:33 AM, Rowan Tommins [IMSoP] = wrote: >=20 > On Wed, 10 Jul 2024, at 07:38, Mike Schinkel wrote: >> The request is to add class maps with a PHP-standardized format into=20= >> PHP core so that when a library of code needs to register classes to = be=20 >> autoloaded they can contribute to a cascading of class maps where ONE=20= >> internal function checks the single union of all class maps for a=20 >> mapped symbol before turning over control if no such symbol is found = in=20 >> the map to the procedural autoloaders that are currently available.=20= >> That way *any* PHP code could register its own class map without = having=20 >> to get the core app to rearchitect itself to allow that to happen. >=20 > Everything you've just described is possible, today, with no changes = to PHP core. I described a **standardized format** that would be processed by PHP, How exactly can any one individual implement a standardized format on = their own, today? One that anyone can depend on to be recognized and = processed by any version of PHP after the one that first implemented it? Rhetorical question. Of course. > So let's step back a second, and look at the pros and cons of = implementing it in core: >=20 > Pros: > - Possibly a bit faster if the C code can be optimised > - "Blessed" by the PHP project, which makes it a standard of sorts Or =E2=80=94 without the blessing of a standard =E2=80=94 as we = sometimes say in the USA: "Besides that Mrs Lincoln, how was the play?" Let me use an analogy. Envision two people on a city council of a small = town. One proposes the city should implement a water, power and sewer = grid so anyone who wants to build a new home or business in the city = would be able to do so easily.=20 The other argues that anyone wanting to build can set up their own = generator, dig their own well, and dig their own septic tank so why = should the city provide such a grid? After all, anyone who is motivated = enough can build "today," right? Clearly that latter argument ignores the value of a central authority = providing infrastructure others can just depend on existing, minimizing = their cost, effort and risk. It also ignores that without that = infrastructure most simply won't build there. In PHP some bits like nice-to-have functions are easy enough to relegate = to userland =E2=80=94 although str_starts_with() and str_ends_with() = sure are nice to just have like a community center in that city which = all residents can use. OTOH, for infrastructure services, PHP benefits = itself and others by providing them even if someone could build the = functionality themselves. =20 To be clear, the fact something is an infrastructure service itself is = not sufficient to argue it *must* be included in PHP core =E2=80=94 the = need for service itself should stand on its own.=20 However, it is enough (IMO) to show "you can do it yourself today" is = not a valid argument against an infrastructure service.=20 So can we please instead focus on the pros and cons of having such an = infrastructure service instead of using the canard "you can build it = yourself" as an argument against roads, power, and sewers? If yes, we should discuss your list of pros and cons.=20 HOWEVER, I think it is probably best to postpone any additional = discussion until after 8.4 is released and any initial bugs are worked = out so anyone interested could focus on the reasoning. > On Jul 10, 2024, at 10:07 AM, Larry Garfield = wrote: >=20 > On Wed, Jul 10, 2024, at 1:38 AM, Mike Schinkel wrote: >=20 >>> In fact, if you use an optimized/dumped autoloader, then Composer = simply builds an internal giant lookup table of what class maps to what = file. PSR-4 is then *completely irrelevant* at runtime. It's already = one giant O(1) lookup map. That can be done *today*. That *is* done = today. >>=20 >> Yes, it can be done today. It *is* done today. By. Developer. = Managed. Apps. >=20 >> Already done. I explained how an `spl_autoload_map()` would do = exactly=20 >> that above. >>=20 >>> When you have a proven that it's even possible to have multiple = local symbol tables, we can talk. Until then, please spare us. >>=20 >> My one useful takeaway from your email =E2=80=94 except that I = already knew=20 >> that =E2=80=94 was the need to figure out how PHP can handle multiple = symbol=20 >> tables. Beyond that, your take your own advice and spare us (me) = from=20 >> your contempt and condescension as they are not good looks on anyone. >=20 > I find it amusing that several of your responses to me saying "you = could do this stupid thing but no one does that" is "WordPress does that = thing." I make no comment other than to observe it. And I observe you are imprecise when making your observation. WordPress as an entity does not do that thing. Plugin developers do. = Independently. Because they have not been given any other viable option. > But let me understand: In a thread started by Michael Morris where he = explicitly said the most important thing for him is multi-version = loading, you're going to insist you're talking only about moving = Composer's classmap logic into core, and nothing about multi-version = loading. Where did you get that from what I wrote? =20 I acknowledged that a next step is doing a proof-of-concept exploration = of multi-symbol tables in PHP core, *not* that needing to be able to = load same-named symbols was something new to me.=20 And Michael Morris proposed spl_autoload_map(). I was just advocating = for it. > If that's the case, then please be polite to Michael Morris and get = out of his thread. Once again, you make incorrect assumptions. > Also, be aware that classmap-in-core was already discussed 3 years ago = and went nowhere. >=20 > https://wiki.php.net/rfc/autoload_classmap > https://externals.io/message/113545 >=20 > Largely because, as Sara said then, and Rowan just said on this = thread, it can be done better in user-space and is already done better = in user-space... by Composer. See the explanation to Rowan above about why doing it in user-space is = not a valid argument against everything that can be done in user-space. > https://externals.io/message/113569 >=20 > You even commented in that thread: >=20 > https://externals.io/message/113554 Yeah, but unlike now I was super busy and could not contribute much to = that debate. > So it's not a new idea, it's an idea that's already been greeted with = a general "meh". Property Hooks were once a general "meh." too. =C2=AF\_(=E3=83=84)_/=C2=AF= > Yes, most "developer managed apps" use Composer today to side-step the = "bajillion autoloaders" problem. It's a solved problem. Or said another way with, in a nod to history "Let them eat cake." > Nothing precludes Wordpress from doing the same. I admittedly have = not looked at WP's core in a very long time, but I would be absolutely = shocked if it wasn't pretty straightforward to build code into WP core = that looks at the source directories of all plugins, finds the classes = there, and builds a big index (stored in a cache directory or the = database) that it can use in one single autoloader registered by WP = itself. I know that can be done, because that's exactly how Drupal 7's = autoloader worked. I know, because I wrote it. In 2008. (It was later = modified by others, but the initial version was mine.) >=20 > That would work even with WP's "download code and drop it on disk" = model. That has been possible since PHP 5.2 at least, when I wrote = exactly that for Drupal. It wasn't even that hard. Literally any "user = managed app" could do the same. >=20 > Why hasn't WP core done that in order to make life easier for plugin = developers and avoid registering 50 separate autoloaders? I dunno, you = should ask Matt Mullenweg. We have nothing to do with it. You make a fair point there.=20 However, as it is a case "anyone could address," no one will. BTW, there is a benefit **beyond** just WordPress developers to having a = core autoload map format in PHP that can just be expected to work. With = that I could publish a library to be used by ANY PHP app, regardless of = what autoloader it needs. Wikipedia even has a few relevant entries: https://en.wikipedia.org/wiki/Interoperability = https://en.wikipedia.org/wiki/Network_effect = =20 That said, as I said above, I am going to go away for now and come back = after 8.4 settles. -Mike --Apple-Mail=_BD693EF5-E8F4-40BF-BCD4-2C1C9FC2E61C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Preface:  I am going to bow out of this = conversation now (unless pulled back in) and come back after 8.4 = settles.

In= the mean time I'll be working on two proof-of-concepts.  One is a = totally userland PoC for packages being able to load same-named symbols, = and the other will be working out how to use multiple symbol tables in = PHP core. And as I have never modified php-src before, that is going to = take some learning.

However, below are responses to Rowan and Larry.


On = Jul 10, 2024, at 8:33 AM, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote:

On = Wed, 10 Jul 2024, at 07:38, Mike Schinkel wrote:
The request is to add class maps with a = PHP-standardized format into
PHP core so that when a = library of code needs to register classes to be
autoloaded = they can contribute to a cascading of class maps where ONE
internal function checks the single union of all class maps = for a
mapped symbol before turning over control if no = such symbol is found in
the map to the procedural = autoloaders that are currently available.
That way *any* = PHP code could register its own class map without having
to= get the core app to rearchitect itself to allow that to happen.

Everything you've just described = is possible, today, with no changes to PHP core. =

I described a = **standardized format** that would be processed by PHP,

How exactly can any one individual implement a = standardized format on their own, today?  One that anyone can = depend on to be recognized and processed by any version of PHP after the = one that first implemented it?

Rhetorical question. Of course.

So let's step back a second, and look at the pros and cons of = implementing it in core:

Pros:
- Possibly a bit faster if the C code can be optimised
- "Blessed" by the PHP project, which makes it a standard of = sorts

Or =E2=80=94 without the blessing of a standard = =E2=80=94 as we sometimes say in the USA: "Besides that Mrs Lincoln, how = was the play?"

Let me use an = analogy.  Envision two people on a city council of a small town. =  One proposes the city should implement a water, power and sewer = grid so anyone who wants to build a new home or business in the city = would be able to do so easily. 

The other argues that anyone wanting to build can = set up their own generator, dig their own well, and dig their own septic = tank so why should the city provide such a grid? After all, anyone who = is motivated enough can build "today," right?

Clearly that latter argument ignores the value of = a central authority providing infrastructure others can just depend on = existing, minimizing their cost, effort and risk. It also ignores that = without that infrastructure most simply won't build there.

In PHP some bits like nice-to-have functions are = easy enough to relegate to userland =E2=80=94 although str_starts_with() = and str_ends_with() sure are nice to just have like a community center = in that city which all residents can use. OTOH, for infrastructure = services, PHP benefits itself and others by providing them even if = someone could build the functionality themselves.  

To be clear, the fact something is an = infrastructure service itself is not sufficient to argue it *must* be = included in PHP core =E2=80=94 the need for service itself should stand = on its own. 

However, it is = enough (IMO) to show "you can do it yourself today" is not a valid = argument against an infrastructure service. 

So can we please instead focus on the pros and = cons of having such an infrastructure service instead of using the = canard "you can build it yourself" as an argument against roads, power, = and sewers?

If yes, we should = discuss your list of pros and cons. 

HOWEVER, I think it is probably best to postpone = any additional discussion until after 8.4 is released and any initial = bugs are worked out so anyone interested could focus on the = reasoning.

On Jul 10, 2024, at 10:07 AM, = Larry Garfield <larry@garfieldtech.com> wrote:

On Wed, Jul 10, = 2024, at 1:38 AM, Mike Schinkel wrote:

In fact, if you use an optimized/dumped autoloader, then = Composer simply builds an internal giant lookup table of what class maps = to what file.  PSR-4 is then *completely irrelevant* at runtime. =  It's already one giant O(1) lookup map.  That can be done = *today*.  That *is* done today.

Yes, it can be done today. It *is* done today.  By. = Developer. Managed. Apps.

Already done.  I = explained how an `spl_autoload_map()` would do exactly 
that above.

When you have a proven that it's even possible = to have multiple local symbol tables, we can talk.  Until then, = please spare us.

My one useful = takeaway from your email =E2=80=94 except that I already knew 
that =E2=80=94 was the need to figure out how PHP can handle = multiple symbol 
tables.  Beyond that, your take = your own advice and spare us (me) from 
your contempt = and condescension as they are not good looks on anyone.

I find it amusing that several of = your responses to me saying "you could do this stupid thing but no one = does that" is "WordPress does that thing."  I make no comment other = than to observe it.

And I observe you are imprecise when making your = observation.

WordPress as an entity = does not do that thing.  Plugin developers do. Independently. = Because they have not been given any other viable option.

But let me understand: = In a thread started by Michael Morris where he explicitly said the most = important thing for him is multi-version loading, you're going to insist = you're talking only about moving Composer's classmap logic into core, = and nothing about multi-version loading.

Where did you get = that from what I wrote?   

I= acknowledged that a next step is doing a proof-of-concept exploration = of multi-symbol tables in PHP core, *not* that needing to be able to = load same-named symbols was something new to me. 

And Michael Morris proposed spl_autoload_map(). =  I was just advocating for it.

If that's the case, then please be polite to = Michael Morris and get out of his thread.

Once again, you make = incorrect assumptions.

Also, be aware that classmap-in-core was already discussed 3 = years ago and went nowhere.

https://wiki.php.net/rfc/autoload_classmap
https://externals.io/message/113545

Largely because, as Sara said then, and Rowan just said on = this thread, it can be done better in user-space and is already done = better in user-space... by Composer.

See the explanation to Rowan above about why doing it = in user-space is not a valid argument against everything that can be = done in user-space.

https://externals.io/message/113569

You even commented in that thread:

https://externals.io/message/113554

Yeah, but unlike = now I was super busy and could not contribute much to that = debate.

So it's not a new idea, it's an idea that's already been = greeted with a general "meh".

Property Hooks were once a general "meh." = too. =C2=AF\_(=E3=83=84)_/=C2=AF

Yes, = most "developer managed apps" use Composer today to side-step the = "bajillion autoloaders" problem.  It's a solved problem.

Or said another = way with, in a nod to history "Let them eat cake."

Nothing precludes = Wordpress from doing the same.  I admittedly have not looked at = WP's core in a very long time, but I would be absolutely shocked if it = wasn't pretty straightforward to build code into WP core that looks at = the source directories of all plugins, finds the classes there, and = builds a big index (stored in a cache directory or the database) that it = can use in one single autoloader registered by WP itself.  I know = that can be done, because that's exactly how Drupal 7's autoloader = worked.  I know, because I wrote it.  In 2008.  (It was = later modified by others, but the initial version was mine.)

That would work even with WP's "download code = and drop it on disk" model.  That has been possible since PHP 5.2 = at least, when I wrote exactly that for Drupal.  It wasn't even = that hard.  Literally any "user managed app" could do the same.

Why hasn't WP core done that in order to make = life easier for plugin developers and avoid registering 50 separate = autoloaders?  I dunno, you should ask Matt Mullenweg.  We have = nothing to do with it.

You make a fair point there. 

However, as it is a case = "anyone could address," no one will.

BTW, there is a benefit **beyond** just = WordPress developers to having a core autoload map format in PHP that = can just be expected to work. With that I could publish a library to be = used by ANY PHP app, regardless of what autoloader it needs. Wikipedia = even has a few relevant entries:

https://en.wikipedia.org/wiki/Interoperability
https://en.wikipedia.org/wiki/Network_effect 

That said, as I said = above, I am going to go away for now and come back after 8.4 = settles.

-Mike

= --Apple-Mail=_BD693EF5-E8F4-40BF-BCD4-2C1C9FC2E61C--