On Wed, Jul 3, 2024 at 7:52 PM Mike Schinkel <m...@newclarity.net> wrote:
> 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. > That's a PSR-4 issue, not an autoloader one. Autoloaders, even in composer, can use class maps to discover which file must be loaded to make the symbol accessible, even if multiple unused symbols in that file come along for the ride. > 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?"* > Brainstorming in a large group is difficult, but not impossible. The last time I tried something like this I did succeed - it was the introduction of runtime assertion to Drupal back in version 8. It took 6 MONTHS of work and debate to get that one accepted, but it has paid off well. If this goes on for a year I wouldn't be surprised. I'm fully prepared for the blind alleys and wrong turns ahead. > > 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. > Uhm, I'm not formally trained so that one got by me - could you please give an example of this? I might have posted one already without realizing it. > > 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. > This last one is essential because something as core to the language must be popular.
