On 26 October 2023 23:35:56 BST, Deleu <deleu...@gmail.com> 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.
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 *namespaces*
work, but about how *autoloading* works. The relevant parts being a) the
ingrained culture of one definition per file (which is not a technical
limitation, but makes certain coding patterns feel alien); and b) the lack of a
universal build stage that can resolve symbols in advance (making it hard to
find a middle way between eager loading all possible definitions, and
postponing loading to runtime).
Luckily with a new concept like type aliases, we don't have the additional
problem that function and constant autoloading faces, of the dynamic fallback
to global scope. So as Mike Schinkel points out, it would be perfectly possible
to have autoloaders that loaded one file per namespace rather than one per type
name, with no changes to the core namespace or autoloading system at all.
In fact, it seems like a namespaced (rather than per-file) type alias would
*have to* use the exact same mechanism as classes etc, because the run-time
won't know it's a type alias until after it's loaded. For example, given
`function foo(\Acme\MyType $bar) { ... }`, 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.
Coming back to the lack of a build stage, that also means type aliases would be
opaque to compile-time optimisations, which are mostly per-file. I'm not sure
what impact that would currently have, but it's worth thinking about.
Regards,
--
Rowan Tommins
[IMSoP]
