> On Jul 3, 2024, at 7:17 AM, Stephen Reay <[email protected]> wrote:
>
> Sent from my iPhone
>
>> On 1 Jul 2024, at 23:33, Mike Schinkel <[email protected]> wrote:
>>
>> Autoloading runs userland code. This means it has the potential conflict between different
>> packages with different autoloaders
>
> *Can* run userland code. It doesn't *have to*; FYI spl_autoload
> (https://www.php.net/manual/en/function.spl-autoload.php <https://www.php.net/manual/en/function.spl-autoload.php>)
> has existed since php5.1 and works amazingly well.
Excellent point!
It has been so long that I have seen anyone use that, however, I actually forgot it exists.
> On Jul 3, 2024, at 10:47 AM, Stephen Reay <[email protected]> wrote:
> Neither of which is the point I was making - someone claimed that autoloaders are implicitly
> userland code. The point is they don't *have* to be, and there is a perfectly useable one built
> in to the SPL extension; if it's "too opinionated" (or the opinions are ones you
> don't like), it's hardly the most in-depth of functions, and it already *has* configurable
> parts, so adding in more control shouldn't exactly require a rocket scientist to add, for
> example, the ability to use the original case of the class name.
Me personally, the opinions that I do not like are the one-symbol-per file assumption, which is also
a key issue I have with PSR-4.
#fwiw.
> On Jul 3, 2024, at 12:51 PM, Matthew Weier O'Phinney <[email protected]>
> wrote:
> I'm following the packaging threads closely, and the one thing I've failed to see a
> solid argument for is _what problems_ the current approach of using namespaced code doesn't
> address. I can definitely see a need for marking things as package private (i.e., not part of the
> publicly consumable API), but that also feels like something we could address in other ways.
Understanding that the thread has been a brainstorming thread more than a proposal thread —
ignoring whether or not it is effective to brainstorm on this list because of interpersonal list
dynamics — my two cents in answer to the question of "What problem(s) are we trying to
solve?"
1. Side-by-side symbol loading — PHP currently makes it difficult if not impossible to use
different versions of the same library as dependencies of higher-level dependencies.
2. Symbol encapsulation — Allowing symbols to be hidden from code that should not use them.
3. Multiple symbols per file — Finding an approach that would be able to gain wide adoption for
multiple symbols per file— without effectively requiring an app to load all source on each page
load — to better support locality of behavior.
See: https://htmx.org/essays/locality-of-behaviour/
4. Unified loading — Currently constants, variables, functions, are the have-nots of the
autoloading realm. Providing a manner for loading them, and a unified manner across all symbols
would be even better.
5. Community buy-in — While not a goal in and of itself, ideally there would be a solution that
would gain broad support over time so the approach does not get dismissed by the majority of
developers simply for reasons such as it is not what they are already familiar with. Having official
PHP endorsement would go a long way to address this.
-Mike