Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124250 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 8BB5D1A009C for ; Sun, 7 Jul 2024 00:01:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1720310562; bh=rYSfgj0W1Ufn0cZxjeDwrtqXmBUI/Dayte485cq1CMs=; h=References:In-Reply-To:From:Date:Subject:To:From; b=lmI6y/CCzWAYbtbBPzATz8fL80dY4jvAuM/iFg+kaYatgkor21gffs1GRFu08wG83 qyws+7ylq4T8liesVI47jYsHdno1nF7AmPjNrVb9XJ8667/wCkzQk6t+JJaRBIZrnO 7SJ89Nh1kzd0iqqETiodJSadOXM9dRe0ENUW0IMOSU2G0p055UySYnv0vUHW3LAcb5 b/RpBBy942gOLqBATtRM27zj4hnCFQMUT2nBNACkHlTwYzhhMw9KpNQmdC2aDVMXhT SPkWd+VFUFJJyqJg4lp/HmbePppUSQIkQeUwt1pNX5MJl5PHxpf+3L0LHgiLF9yJUd HR00AiOVupbJQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D624D1801DE for ; Sun, 7 Jul 2024 00:02:40 +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-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) (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 ; Sun, 7 Jul 2024 00:02:40 +0000 (UTC) Received: by mail-qk1-f175.google.com with SMTP id af79cd13be357-79efccad5e1so113038285a.0 for ; Sat, 06 Jul 2024 17:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720310475; x=1720915275; 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=74RjaQhhObehiuAljyCygrdnsfPqlCYDBEAKkosdfS8=; b=IZ2bpkdOu9kYD+6w3VJtgHjOAcqYXTc5izS7B0i209aNM+kWJ48OvE0g0cFdps6aqk BtsBgK2989KZEo4bMkQufxb7+5PpHJOD1B7c0Sdbd5tWIfGLuBdQQCCvF+zXsICpepX7 erYg/XbyTgQbr0soA5azHv74a7jCt06VMtOZ1uYwzNO53qJE3yv7Mm0wqR2tBIDmnDF1 F1FHFu5m+fIrK4lgWRjh0xR/cBljBBzHbi8hTTPKCwLnz2siFqmldBceN+d+iLUSHRPY nZhvY5e+/Zw2XI9aDPvQhNjQfCVVtlVIVtQjodKf/FvktLiYbb/wRCD59F+qZHVxhyRD mh1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720310475; x=1720915275; 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=74RjaQhhObehiuAljyCygrdnsfPqlCYDBEAKkosdfS8=; b=bnS+2c2+AvL9jkQV1YTIVojssQ9kcmZP7MFlOvMRTTNUfh3u1vHYva0Mh6bneWTTTt c4oYpUOtrK+NXMtXUTVT/58XYh+gbCK2VI4U2p8MCv9ZUa8/Z+aoXsQcRaO/0iFlK7b5 tErINLgs9Cpi1gbHuQS+JuM7eQ9rTDwx5YOMZXHt8wzNyZvHF1P1QqTvVFevQoIL2Xxw HRQoto80k5BsHPO0H5kpGoY5E5d6Euo04cGtd7iMpM2iRNs3C/EYrjZrpQ8px1DSMsBq /63E5hKzwuUgISoDzDo8s+5EjKhK9vX4/Nqy4+WT43c7xlaawmmFiabBPQQHu4Ah2ZMW 43Kw== X-Gm-Message-State: AOJu0Yx4WY4NfHolrz1Fs4Chg59y7iKT7pQrGipi92qKtaYPuPJxEpqk ehzX1Ezg+49kUrMqbYDiG61G4+m2/m707yHfJywWW/i84LrnYPsT3zllZOC9UOidMBNBbhvwmtG OOZGtJ88UNd9Ezr1iNHHa5846P+XN9QnE X-Google-Smtp-Source: AGHT+IFZMgG3+KgqRhkBCvg9rubUAyjkbvFfXwzxv9NwVtP449E3XIGLsAw4bHuILCaphOq8Wuy1AQcsjwrmAZz4YWI= X-Received: by 2002:ad4:5aee:0:b0:6b5:e3fe:e734 with SMTP id 6a1803df08f44-6b5ecfb22fcmr114959646d6.3.1720310475335; Sat, 06 Jul 2024 17:01:15 -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> <0E11F373-99DC-496E-9BBC-2F8688B9F66A@newclarity.net> <4F720A7A-B7DD-4B31-B0C9-6907419B53A5@newclarity.net> In-Reply-To: Date: Sat, 6 Jul 2024 20:01:03 -0400 Message-ID: Subject: Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV) To: PHP internals Content-Type: multipart/alternative; boundary="000000000000c92f47061c9cfe1b" From: tendoaki@gmail.com (Michael Morris) --000000000000c92f47061c9cfe1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 6, 2024 at 2:12=E2=80=AFAM Mike Schinkel = wrote: > On Jul 5, 2024, at 1:47 PM, Michael Morris wrote: > I went to sleep thinking about this post, on import maps in general and > how Composer works, specifically when you use a class map instead of the > PSR-0 or PSR-4 schemes. In that mode, Composer does pretty much what I'v= e > described. This got me to thinking, could setting an import map be an > alternative to setting an autoload function? Would having the PHP runtim= e > load the file be faster than mucking with some userland code to do the > same? And would the engine be able to do anything that can't be done in > userland? I think so. > > > I very much like this direction of thought. > > For context, when I worked with WordPress for about a decade I only ever > used only Composer for websites but never for my own plugins, and I almos= t > never used namespaces nor PSR-4 autoloaders for anything except when a > plugin used them. I almost exclusively used naming convensions for > "namespacing" and classmaps for autoloading. > Some context from where I'm coming from. I have been working exclusively in React, NodeJS and Go up till about a year ago, and in Drupal before that - it being 10 years since the last time I looked at WordPress. I need work though, and I was offered a job where about two-thirds of my workload is a massive WordPress site that has grown well outside the scope WordPress does best. So I've been getting used to it again and added some ulcers along the way. > Obviously I agree with having only one format, but not sure I concur with > the use of .ini. However, me debating against `.ini` would be me > bikeshedding and thus I will demure here. > I'm not married to ini either, but it will work for illustration. Adopting another format will be one of the first decisions to make come implementation. > > ... > Many (most?) people on PHP Internals view WordPress coding standards as > bad and some even view addressing WordPress developers needs as bad for > PHP.... > I really don't want to get into that crossfire. WordPress is the 800lb. gorilla of the PHP app world having more server market share that is dominant - how dominant depends on who you ask. The most conservative estimate I've seen is about half of PHP sites are running WordPress, and the most pro-WP quote I saw claimed it has around 80% share. > ; A path fragment can be used, in which case PSR-4 will be used to map > the rest of the symbol to the filename. > > ; Pay attention to the direction of the slash at the tail - if the > symbol key has this the value MUST also have this. > B/ =3D './path/to/B/' > > > It is not clear to me what a trailing slash means, and especially why it > is needed on the left-hand side? > This is taken from the JavaScript importmap specification, but it exists to cordon off direct file includes from directory includes. Original spec here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/impor= tmap > And why slash here when namespaces use backslash? > Because it's the end of a path and unless you're on Windows directories are delimited with /. They aren't the same thing > > Also, as someone raised on DOS and then Windows only "converting" in 2009= , > I still get confused in *nix when to use a trailing slash and when to not= , > so this trailing slash worries me, if only for that reason alone. > I understand. Here it's to call out that the key references a directory, not a file. The value must explicitly be a directory, not a file, and a trailing slash is the way that is done. Files are not *required* to have extensions after all. > > Using the `@` here feels cryptic, and hard to discover and remember. > Perhaps, but this file is meant to be assembled by composer or some other automated means - not by hand. @ as a package operator is used in Node.js to mark package namespaces - essentially the vendor of the package is marked with @. > > I think this would be infinitely easier to follow if packages were just > included in a `[packages]` section. > Packages will need to have some special handling though. And the questions I'm getting make that point increasingly clear. If, as Larry Gafield has stated, the engine cannot be made to maintain multiple symbol tables, then the packages must be bound onto the master symbol table. This presents a problem if multiple packages with different versions are to be installed. One way to resolve this is some chicanery. If PHP is instructed to install a file as a "package" it could load it onto the symbol table in an auto-generated namespace - say \pkg_hash\Twig - and then symbolic link to the package from other namespaces that are referencing it. Packages can (must) include other packages as their dependencies. If the symlinks are done right the end programmers do not need to concern themselves with this implementation detail. But the legacy code in the package itself needs to believe it is where it expects to be - on root. When a Twig file calls to another Twig file it calls `use Twig\Class` in some form or another. Monkey patching such as what happens in https://packagist.org/packages/brianhenryie/strauss file accomplishes this in userland by rewriting the files. The whole of the namespace resolution system is on the fly file renaming, so doing this in the engine should be possible. ; An import into a package can be done like so ; Twig will load into \C\Twig and that use will need to be used by any code outside the C package. @C\Twig/ =3D './path/to/Twig/' > Your comments also confuse me a bit. > > Is this saying that your hypothetical app =E2=80=94 which you stated this= `.ini` > file is for =E2=80=94 needs to use a package named `C` use "definition" i= s located > at './path/to/C/autoload.ini' then it would use this syntax, and that in > the app its components would be accessed at namespace `\C`? > Packages can have an ini file, but they are not REQUIRED to have one. Otherwise, the existing library of packages will not be loadable because they do not have such files. Without the @ operator the library wouldn't load correctly because all the files in Twig, parsed normally, will load to \Twig. The @C\ tells PHP to prefix C to every namespace declaration loaded in that directory and each use statement. This is a new behavior entirely and needs to be carefully considered. > > And I were to have: > > @Foo\Bar\Baz =3D './path/to/Foo/Bar/Baz/autoload.ini' > > > Then in the app its components would be accessed at namespace > `\Foo\Bar\Baz`? > Yes. > > Okay, this makes sense. OTOH, this is the part that of your proposal tha= t > is incomplete for the needs of User-managed apps IMO. > This is the part that needs the most scrutiny overall. > > I think you are implying a necessary "best practice" that whenever any PH= P > library, or package would include code they would need to prefix the > namespace of package when importing it and then when using it. Given an o= rg > named ACME that released a library called Widgets then if it were to use > Twig it should import and use Twig like this* (did I understand your > intent correctly?):* > > @ACME\Widgets\Twig/ =3D './path/to/Twig/' > > And in PHP code?: > > use \ACME\Widgets\Twig; > Or namespace ACME\Widgets; use Twig\Extension; Namespace resolution rules can be tricky. > > I think that would work well for newer libraries and packages authored an= d > used by developers of Developer-managed apps. OTOH I do not think it woul= d > be sufficient for any existing libraries or frameworks, nor for > non-professional developers scratching their own itch on a User-managed > apps and then deciding to publish it for others to use *(which happens a > lot with User-managed apps.)* > > The problem would be that most (all?) of those would not be > namespace-prefixing Twig but instead using it directly. I believe you nee= d > an ADDITIONAL `replace` sectionS that allowed an app/website developer to > indicate that namespace A should instead be replaced in `use` statements > and direct references with `B\A` for code that exists in directory(s) `C` > but not in directories `C\D` where `C` and `D` can be globs. > > ... > > [replace] > Twig[UpdraftPlus] =3D 'Twig_edaf27eb' > Twig[Elementor] =3D 'Twig_edaf27eb' > > No, PHP should handle this quietly under the hood without needing the autocomplete author to do this whether it is a person or a userland program like Composer. > And lastly, because WordPress would need to generate this and having a we= b > app write to a file is a modern security no-no, then `spl_autoload_map()` > should accept multiple different valid values: > > spl_autoload_map( string|array|\PHP\AutoloadMap $map); > > 1. String would be the `.ini` file path > > 2. Array would be the format returned by parse_ini_file() for parsing an > applicable `.ini` file > > 3. \PHP\AutoloadMap could be a new class containing the required values i= n > object format. *(Hopefully adding such a class as a third option would > not be controversial to the list members who criticize those developers > still wanting to use arrays as hash maps?)* > > And that is about it for my feedback today. > > I'm not opposed to that. Indeed, doing that would allow for additional formats without the overhead of directly maintaining them spl_autoload_map(json_decode('autoload.json')) ________ Now earlier today I had a thought that shook me. The entry point of the application in this example will likely call this function before anything else, just as applications like Drupal call the autoload require before anything else. So, why not call the map first? then let the map designate the entry point? A HUGE Can of opportunity worms opens. This is also a wild tangent, but again this is a brainstorm thread. ; First this autoload map needs to tell PHP what it is. A Package, or an application. map_type =3D application ; The Setup files are those which always need to be run before the application is ; ready to do anything. These files will be loaded with NO ACCESS to globals or ; or super globals. The engine's state after running these files will be op cached and ; each subsequent request starts from here. This allows the considerable setup work ; that applications like Drupal do to be resolved only once and then start from that ; cache. This is also the reason why superglobals aren't visible to these files - the ; state cannot make decisions about any specific request because they'd bleed into ; subsequent requests - a potential security nightmare. ; ; Note the autoloader of this script will be setup in full before these files parse. [setup] [] =3D 'path/to/first/setup/file.php' [] =3D 'path/to/second/setup/file.php' Just a thought. --000000000000c92f47061c9cfe1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jul 6, 2024 at 2:12=E2=80=AFA= M Mike Schinkel <mike@newclarity.= net> wrote:
On Jul 5, 2024= , at 1:47 PM, Michael Morris <tendoaki@gmail.com> wrote:
=
I went to = sleep thinking about this post, on import maps in general and how Composer = works, specifically when you use a class map instead of the PSR-0 or PSR-4 = schemes.=C2=A0 In that mode, Composer does pretty much what I've descri= bed.=C2=A0 This got me to thinking, could setting an import map be an alter= native to setting an autoload function?=C2=A0 Would having the PHP runtime = load the file be faster than mucking with some userland code to do the same= ? And would the engine be able to do anything that can't be done in use= rland?=C2=A0 I think so.

I very much like this direction of thought.

= For context, when I worked with WordPress for about a decade I only ever us= ed only Composer for websites but never for my own plugins, and I almost ne= ver used namespaces nor PSR-4 autoloaders for anything except when a plugin= used them.=C2=A0 I almost exclusively used naming convensions for "na= mespacing" and classmaps for autoloading.=C2=A0

Some context from where I'm coming fr= om.=C2=A0 I have been working exclusively in React, NodeJS and Go up till a= bout a year ago, and in Drupal before that - it being 10 years since the la= st time I looked at WordPress. I need work though, and I was offered a job = where about two-thirds of my workload is a massive WordPress site that has = grown well outside the scope WordPress does best.=C2=A0 So I've been ge= tting used to it again and added some ulcers along the way.
=C2= =A0
Obviously I agree with having only one format, but not sure= I concur with the use of .ini. However, me debating against `.ini` would b= e me bikeshedding and thus I will demure here.
<= /blockquote>

I'm not married to ini either, but it w= ill work for illustration. Adopting another format will be one of the first= decisions to make come implementation.
=C2=A0
=
<epiphany>
...
Many (most?) p= eople on PHP Internals view WordPress coding standards as bad and some even= view addressing WordPress developers needs as bad for PHP....
<= /div>

I really don't want to get = into that crossfire.=C2=A0 WordPress is the 800lb. gorilla of the PHP app w= orld having more server market share that is dominant - how dominant depend= s on who you ask. The most conservative estimate I've seen is about hal= f of PHP sites are running WordPress, and the most pro-WP quote I saw claim= ed it has around 80% share.



<= /div>
=C2=A0 ; A path fragment ca= n be used, in which case PSR-4 will be used to map the rest of the symbol t= o the filename.
=C2=A0 ; Pay attention to the direction of the slash at= the tail - if the symbol key has this the value MUST also have this.
=C2=A0 B/ =3D './path/to/B/'

It is not clear to me wh= at a trailing slash means, and especially why it is needed on the left-hand= side?

This is taken fro= m the JavaScript importmap specification, but it exists to cordon off direc= t file includes from directory includes. Original spec here:=C2=A0https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/= type/importmap
=C2=A0
And why slash here when name= spaces use backslash?

Bec= ause it's the end of a path and unless you're on Windows directorie= s are delimited with /. They aren't the same thing
=C2=A0
<= div>
Also, as someone raised on DOS and then Windows only &qu= ot;converting" in 2009, I still get confused in *nix when to use a tra= iling slash and when to not, so this trailing slash worries me, if only for= that reason alone.

I und= erstand.=C2=A0 Here it's to call out that the key=C2=A0references a dir= ectory, not a file. The value must explicitly be a directory, not a file, a= nd a trailing slash is the way that is done.=C2=A0 Files are not *required*= to have extensions after all.

=C2=A0

<= /div>
Using the `@` here feels cryptic, and hard to discover and rememb= er.

Perhaps, but this fil= e is meant to be assembled by composer or some other automated means - not = by hand.=C2=A0=C2=A0@ as a package operator is used in Node.js to mark pack= age namespaces - essentially the vendor of the package is marked with=C2=A0= @.=C2=A0=C2=A0
=C2=A0

I think this would be= infinitely easier to follow if packages were just included in a `[packages= ]` section.

Packages = will need to have some special handling though.=C2=A0 And the questions I&#= 39;m getting make that point increasingly clear.

I= f, as Larry Gafield has stated, the engine cannot be made to maintain multi= ple symbol tables, then the packages must be bound onto the master symbol t= able.=C2=A0 This presents a problem if multiple packages with different ver= sions are to be installed. One way to resolve this is some chicanery.=C2=A0= If PHP is instructed to install a file as a "package" it could l= oad it onto the symbol table in an auto-generated namespace - say \pkg_hash= \Twig - and then symbolic link to the package from other namespaces that ar= e referencing it.=C2=A0 Packages can (must) include other packages as their= dependencies.=C2=A0 If the symlinks are done right the end programmers do = not need to concern themselves with this implementation detail.
<= br>
But the legacy code in the package itself needs to believe it= is where it expects to be - on root.=C2=A0 When a Twig file calls to anoth= er Twig file it calls `use Twig\Class` in some form or another.
<= br>
Monkey patching such as what happens in=C2=A0https://packagist.org/packa= ges/brianhenryie/strauss file accomplishes this in userland by rewritin= g the files.=C2=A0 The whole of the namespace resolution system is on the f= ly file renaming, so doing this in the engine should be possible.

=C2= =A0 ; An import into a package can be done like so
=C2=A0 ; Twig will load into \C\Twig and tha= t use will need to be used by any code outside the C package.
=C2=A0=C2= =A0@C\Twig/ =3D './path/to/Twig/'

Your comments also confuse me a bit. =C2=A0=

Is this saying that your hypothetical app =E2=80= =94 which you stated this `.ini` file is for =E2=80=94 needs to use a packa= ge named `C` use "definition" is located at=C2=A0'./path/to/C= /autoload.ini' then it would use this syntax, and that in the app its c= omponents would be accessed at namespace `\C`?

Packages can have an ini file, but they are not= REQUIRED to have one.=C2=A0 Otherwise, the existing library of packages wi= ll not be loadable because they do not have such files.=C2=A0 Without the= =C2=A0@ operator the library wouldn't load correctly because all the fi= les in Twig, parsed normally, will load to \Twig.=C2=A0 The=C2=A0@C\ tells = PHP to prefix C to every namespace declaration loaded in that directory and= each use statement. This is a new behavior entirely and needs to be carefu= lly considered.
=C2=A0

And I were to h= ave:

@Foo\Bar\Baz =3D './path/to/Foo/Bar/Baz/autoload.ini'

Then in the app its components would be accesse= d at namespace `\Foo\Bar\Baz`?

Ye= s.
=C2=A0
=

Okay, this makes sense.=C2=A0 OTO= H, this is the part that of your proposal that is incomplete for the needs = of User-managed apps IMO.

This is the part that needs the most scrutiny overall.

=C2=A0

I think you are implying a necessar= y "best practice" that whenever any PHP library, or package would= include code they would need to prefix the namespace of package when impor= ting it and then when using it. Given an org named ACME that released a lib= rary called Widgets then if it were to use Twig it should import and use Tw= ig like this (did I understand your intent correctly?):
@ACME\Widgets\Twig/ =3D './path/to/Twig/'
<= div>
And in PHP code?:
<= div>

use \ACME\Widgets\Twig;

Or=C2=A0

=C2=A0 namespace ACME\Widgets;
=C2=A0 use Twig\Extension;
=
Namespace resolution rules can be tricky.
=C2=A0

I think that would work well for newer libraries = and packages authored and used by developers of Developer-managed apps. OTO= H I do not think it would be sufficient for any existing libraries or frame= works, nor for non-professional developers scratching their own itch on a U= ser-managed apps and then deciding to publish it for others to use (whic= h happens a lot with User-managed apps.)

The p= roblem would be that most (all?) of those would not be namespace-prefixing = Twig but instead using it directly. I believe you need an ADDITIONAL `repla= ce` sectionS that allowed an app/website developer to indicate that namespa= ce A should instead be replaced in `use` statements and direct references w= ith `B\A` for code that exists in directory(s) `C` but not in directories `= C\D` where `C` and `D` can be globs.
=C2=A0
=
...
[replace]
Twig[UpdraftPlus] =3D 'Twig_edaf27eb&=
#39;
Twig[Elementor] =
=3D 'Twig_edaf27eb'

No, PHP sho= uld handle this quietly under the hood without needing the autocomplete aut= hor to do this whether=C2=A0it=C2=A0is a person or a userland program like = Composer.=C2=A0



And lastly, becaus= e WordPress would need to generate this and having a web app write to a fil= e is a modern security no-no, then `spl_autoload_map()` should accept multi= ple different valid values:

spl_autolo= ad_map( string|array|\PHP\AutoloadMap $map);

= 1. String would be the `.ini` file path

2. Array w= ould be the format returned by parse_ini_file() for parsing an applicable `= .ini` file

3. \PHP\AutoloadMap could be a new clas= s containing the required values in object format. (Hopefully adding suc= h a class as a third option would not be controversial to the list members = who criticize those developers still wanting to use arrays as hash maps?)

And that is about it for my feedback today.


=
I'm not opposed to that. Indeed, doing that would allow for additi= onal formats without the overhead of directly maintaining them
spl_autoload_map(json_decode('aut= oload.json'))

________

Now earlier today I had a thought that shook me.=C2=A0 The entry p= oint of the application in this example will likely call this function befo= re anything else, just as applications like Drupal call the autoload requir= e before anything else.

So, why not call the map f= irst? then let the map designate the entry point?

= A HUGE Can of opportunity worms opens. This is also a wild tangent, but aga= in this is a brainstorm thread.

=C2=A0 ; First this autoload map needs to tell PHP what it is.=C2=A0= A Package, or an application.
= =C2=A0 map_type =3D application
<= br>
=C2=A0 ; The Setup files are = those which always need to be run before the application is
=C2=A0 ; ready to do anything.=C2=A0 These files= will be loaded with NO ACCESS to globals or
=C2=A0 ; or super globals. The engine's state after running= these files will be op cached and
=C2=A0 ; each subsequent request starts from here.=C2=A0 This allows the = considerable setup work
=C2=A0 ; = that applications like Drupal do to be resolved only once and then start fr= om that
=C2=A0 ; cache. This is a= lso the reason why superglobals aren't visible to these files - the
=C2=A0 ; state cannot make decisions= about any specific request because they'd bleed into
= =C2=A0 ; subsequent requests - a potential securit= y nightmare.
=C2=A0 ;
=C2=A0 ; Note the autoloader of this script = will be setup=C2=A0in full before these files parse.
=C2=A0 [setup]
=C2=A0 =C2=A0 [] =3D 'path/to/first/setup/file.php'
<= div>=C2=A0 =C2=A0 [] =3D 'path/to/second/setup= /file.php'

Just a thought.
= =C2=A0
--000000000000c92f47061c9cfe1b--