Hi Marco!
First of all, please do stick around, and keep learning and being
curious. Sometimes out of the box thinking does get somewhere.
That said, a lot of what you've written here is actually what already
happens, and the problems are elsewhere.
On 21/04/2023 04:54, Deleu wrote:
1- Use include/require
2- Custom Autoloading (not for functions but bear with me)
3- Use Composer/PSR-4
The first thing to note is that these aren't *options*, they're *layers*
on top of each other: to load some code from a file, you use
include/require; to load some code *on demand*, you write an autoload
function, which uses include/require; to let *someone else* write that
function, you lay your files out according to PSR-4 and use Composer,
which writes the autoload function, which uses include/require.
Here I want to raise the discussion about the little I know about PHP
symbols. If a symbol `interface Foo` is discovered and registered by PHP,
it will be usable as an interface throughout its entire execution. If the
symbol is not discovered and is used, it will trigger autoloading as a
last-chance before fatal error.
Yes, when PHP needs the definition of a class/interface, etc, it looks
up its name in a table. If it's not there, it can pass the name to an
autoload function, and then try again (after the function has,
hopefully, included a file with an appropriate definition).
In fact, the table is shared between classes, interfaces, traits, and
enums, which is why you can't have overlapping names between them, and
why they all trigger the same autoloader. This makes sense because
they're often used in the same context - e.g. in "$foo instanceof Foo",
"Foo" can be a class, an interface, or an enum.
I'll come back to type aliases in a second, but first:
can `function bar() {}` be a symbol?
It already is. When you run foo('bar'), PHP has to look up what the
definition of "foo" is in a table of functions. In principle,
autoloading could work for those just the same way it does for classes
... except for one awkward feature which seemed like a good idea 15
years ago. If you write this:
namespace Foo {
echo strlen('hello');
}
Should PHP lookup the function "\Foo\strlen", or the function "\strlen"?
The "clever" answer 15 years ago was to do *both*: try the namespaced
name first, then if it doesn't exist, try the global name. This does not
happen for classes, only for functions and constants.
This is a real pain for autoloading: how do you avoid repeatedly calling
the autoloader looking for "\Foo\strlen", finding there's still no
definition, and falling back to "\strlen"? That's one of the main points
of discussion whenever function autoloading comes up.
Can `type Number = int|number;` be a symbol?
Can `type TwoInts = callable(int $x, int $y): int;` be a symbol?
Fundamentally, yes. They'd probably need to occupy the same lookup table
as classes - if I write "function foo(SomeType $someArg)", PHP doesn't
know until it's looked it up whether "SomeType" is a type alias or class
- but that's not a big problem.
I think there is some discussion around whether people *want* it to work
that way - should it be more like a "use" statement, and just take
effect for the current file? Then there's questions around how to
actually implement it, and do so efficiently. But creating a table of
names to types isn't the hard part of the problem.
Now one questionable user experience I see is defining:
- 1 Class = 1 File
[...]
But this user experience does not come from PHP's nature, but instead it
comes from Composer/PSR-4 because PSR-4 maps namespaces to directories and
symbols to files.
Precisely. PHP doesn't need to do anything to change this, it's entirely
up to users. There are ways that PHP might be able to optimise for
different use cases, but the power of the autoloader being a callback
function is that it can do whatever you want it to. It doesn't even need
to involve files at all, if you don't want it to.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
