Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121476
MIME-Version: 1.0
References: <CAHXoPRtjsPzgpYnhB05hjdZo6Q-MDr4TUGbn9LQ77-hKVTCZOA@mail.gmail.com>
 <e94b0021-b18d-4c48-8764-6d4909142b26@app.fastmail.com>
In-Reply-To: <e94b0021-b18d-4c48-8764-6d4909142b26@app.fastmail.com>
Date: Thu, 26 Oct 2023 19:35:56 -0300
Message-ID: <CADK1yXJhYc7hxa3-oLYqk0+hNy1FPFwUfRAD+Qej3Op1P3jAyg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000228b1b0608a63400"
Subject: Re: [PHP-DEV] Basic Type Alias
From: deleugyn@gmail.com (Deleu)

--000000000000228b1b0608a63400
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 26, 2023 at 4:23=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com>
wrote:

> On Thu, Oct 26, 2023, at 6:37 AM, Oladoyinbo Vincent wrote:
>
> App-wide aliases run into the autoloading problem.  If the engine runs
> across the add() function above, and "numeric" isn't defined, what can it
> do?  Currently, all it can do is trigger autoloading, which only works fo=
r
> class-ish constructs (class, interface, trait, enum).  Making type aliase=
s
> a full class-like construct seems... weird, and over-engineered.  But if
> not, how do we autoload them?  And if they do autoload somehow, does that
> mean we end up with a bunch of files with a single `type` line in them?
> That seems not-good.  You also then have to ask how they interact with
> namespaces.
>
> So far no one seems to like my idea of "composer has a files block, PHP
> has a preloader, they're small, so who the hell cares about autoloading,
> just greedily load them and move on with life", even though I think that'=
s
> the best answer. :-)
>
> So any type alias proposal would need to sort out the above "definition
> problem" in a way that's generally acceptable.  That's been the hold up f=
or
> 3 years, I think.
>
> I'm also not sure why you're mentioning generics at all.  Type aliases
> would be helpful with generics, but they're also helpful without generics=
.
> They're orthogonal and not especially related.  I agree that there's no
> reason to wait for generics to add type aliases.
>
> --Larry Garfield
>

Unless someone else has good points to raise, it sounds like there's a
clear sign that file-based type aliases are not useful for PHP.

With that in mind, the discussion seems to point straight to autoloading. I
think this shows a limitation with PHP Namespaces and Autoloading
capabilities. I really don't want to judge/belittle/speak ill of something
that was first released 14 years ago, which means discussion and planning
had to have happened even earlier than that. Everything was completely
different back then.

What I see today is that PHP Namespaces seem to have succeeded thanks to
Composer and PSR-4. Working without Composer in 2023 doesn't seem like a
reality to me. Maybe I'm biased/young and if this premise is "too wrong"
then everything else I say after this might be discarded.

PHP Namespaces, Composer and PSR-4 can't really recreate the experience
that ESM provides because 1) Namespaces itself aren't tied to file paths
and 2) PHP doesn't have a build process (path aliases, Typescript types).
What Composer and PSR-4 offers is a static build tool that runs once
(composer dump-autoload) and creates namespace-to-folder mapping that can
be used to discover symbols without a continuous build process or a
continuous `composer dump-autoload --watch`.

Now my question is: Why PHP Namespace limitation SHOULD be a deciding
factor when talking about Type aliases? The problem is there and exists and
is dealt with as best as it can by the union of PHP Namespaces + Composer +
PSR-4. PHP already has a few symbols that require discovery: Class,
Interface, Enum, Traits and they're all tied to autoloading in case they
haven't been discovered yet. If a Type Alias triggers autoloading,
developers are free to:

1- Implement Type Aliases using 1-file-per-type-alias (PSR-4 compatible).
2- Create a single type-to-rule-them-all.php and rely on Composer File
autoload (greedy).
3- Write a custom autoloading function that deals with the problem however
they want.
4- Manually `require_once` type-aliases files where they know they need to
be used.
5- Not use Type Alias.

To build up on my question, suppose someone one day comes up with a
solution to PHP Namespace problems (that already affects interfaces,
classes, enums and traits). Could Type Alias make it worse enough that such
a hypothetical solution would be rendered impossible because Type Aliases
were introduced in PHP? Does preventing PHP from having Type Aliases that
comply with the current reality of the project benefit the project in any
meaningful way that it will be easier for something in the future to be
made better?

I know it's hard to talk about hypothetical solutions when we don't know
what they are, but I think we can ballpark that interfaces, classes, enums
and traits are important enough that an enhancement to PHP Namespace system
needs to bring enough benefit without a BC break to be voted in. And such
improvement could just as easily take into consideration type aliases as
one extra thing.

Maybe my lack of knowledge on PHP Source code makes me think that Type
Aliases aren't a big deal as they could be and some insight into that could
shed some light into why this is too simplistic thinking. The simplistic
thinking being: Take Namespaces as they were designed 15 years ago and add
Type Aliases into the mix. Back then a solution decoupled from the
filesystem was introduced and a userland autoloading function was the slim
layer that made PHP Namespaces what they are. We can build on top of that
mindset with type aliases. We need a syntax to declare them and an
autoloading userland function to find where they are declared. Everything
else can fall into place as it did before.

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.

If this line of thought has any merit, a better question would be whether
Type Alias needs a separate autoload function from class/interfaces or a
single autoload is better. I think that's the kind of discussion that would
help Composer/PSR to decide how to expand and improve the PHP Ecosystem to
include handling of Type Aliases.

--=20
Marco Deleu

--000000000000228b1b0608a63400--