Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120098
Message-ID: <6581c252-75c9-889d-75d2-eff5220216c2@gmail.com>
Date: Fri, 21 Apr 2023 10:02:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
To: internals@lists.php.net
References: <CADK1yXJqCXFGOAmo_-iyGOqXsDJMGMs2L7PCT1zkvsHk+9y46w@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CADK1yXJqCXFGOAmo_-iyGOqXsDJMGMs2L7PCT1zkvsHk+9y46w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Expansion of PHP Symbols?
From: rowan.collins@gmail.com (Rowan Tommins)

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]