> On Jul 3, 2024, at 7:17 AM, Stephen Reay <php-li...@koalephant.com> wrote:
>
> Sent from my iPhone
>
>> On 1 Jul 2024, at 23:33, Mike Schinkel <m...@newclarity.net> 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 <php-li...@koalephant.com> 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
> <mweierophin...@gmail.com> 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
