Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121491
Date: Sat, 28 Oct 2023 14:22:16 +0100
To: internals@lists.php.net
User-Agent: K-9 Mail for Android
In-Reply-To: <CADK1yXJhYc7hxa3-oLYqk0+hNy1FPFwUfRAD+Qej3Op1P3jAyg@mail.gmail.com>
References: <CAHXoPRtjsPzgpYnhB05hjdZo6Q-MDr4TUGbn9LQ77-hKVTCZOA@mail.gmail.com> <e94b0021-b18d-4c48-8764-6d4909142b26@app.fastmail.com> <CADK1yXJhYc7hxa3-oLYqk0+hNy1FPFwUfRAD+Qej3Op1P3jAyg@mail.gmail.com>
Message-ID: <013A586C-26A9-454A-B855-E5474EB62B91@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary=----R0C4H131ABPJG9MWSM9TJ2BZ8W6R21
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Basic Type Alias
From: rowan.collins@gmail.com (Rowan Tommins)

------R0C4H131ABPJG9MWSM9TJ2BZ8W6R21
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 26 October 2023 23:35:56 BST, Deleu <deleugyn@gmail=2Ecom> wrote:
>I would love it if we could bring up a discussion on proposing changes to
>the PHP Namespace system to allow for something more like ESM while
>considering we don't have a build system and a hot-reload system, but I'm
>just not sure if PHP Type Aliases is where that discussion MUST to happen=
=2E

For those of us not familiar, can you provide a two or three line summary =
of ESM, and what you think it provides that PHP currently lacks?

As I understand it, the debate has generally not been about how *namespace=
s* work, but about how *autoloading* works=2E The relevant parts being a) t=
he ingrained culture of one definition per file (which is not a technical l=
imitation, but makes certain coding patterns feel alien); and b) the lack o=
f a universal build stage that can resolve symbols in advance (making it ha=
rd to find a middle way between eager loading all possible definitions, and=
 postponing loading to runtime)=2E

Luckily with a new concept like type aliases, we don't have the additional=
 problem that function and constant autoloading faces, of the dynamic fallb=
ack to global scope=2E So as Mike Schinkel points out, it would be perfectl=
y possible to have autoloaders that loaded one file per namespace rather th=
an one per type name, with no changes to the core namespace or autoloading =
system at all=2E

In fact, it seems like a namespaced (rather than per-file) type alias woul=
d *have to* use the exact same mechanism as classes etc, because the run-ti=
me won't know it's a type alias until after it's loaded=2E For example, giv=
en `function foo(\Acme\MyType $bar) { =2E=2E=2E }`, the runtime knows only =
that `\Acme\MyType` is something that can describe a type, not whether that=
 is a class, interface, enum, or type alias=2E=20

Coming back to the lack of a build stage, that also means type aliases wou=
ld be opaque to compile-time optimisations, which are mostly per-file=2E I'=
m not sure what impact that would currently have, but it's worth thinking a=
bout=2E

Regards,
--=20
Rowan Tommins
[IMSoP]
------R0C4H131ABPJG9MWSM9TJ2BZ8W6R21--