Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125472
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
Subject: Re: [PHP-DEV] bikeshed: Typed Aliases
In-Reply-To: <0d461700-1b6c-44fd-9cda-aa698de49847@app.fastmail.com>
Date: Sat, 7 Sep 2024 09:23:13 -0700
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <667233C2-BC47-4530-8142-D90E6907FE63@daveyshafik.com>
References: <0fa39535-f22d-4eba-b4df-90abe39e683a@app.fastmail.com>
 <e73be2b0-faa9-42eb-a9f6-8308cf4f8c94@app.fastmail.com>
 <ed3847bf-af2e-4e33-ac09-66e44696fdeb@app.fastmail.com>
 <79e58673-50ec-461e-a998-736b020e4287@app.fastmail.com>
 <a3cd6d90-cfac-40d5-a59a-c9f6d9dbe5f0@app.fastmail.com>
 <928A2984-6035-4DA6-9EA7-12E85237C270@php.net>
 <0d461700-1b6c-44fd-9cda-aa698de49847@app.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
From: me@daveyshafik.com (Davey Shafik)


> On Sep 7, 2024, at 06:28, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> On Fri, Sep 6, 2024, at 7:46 PM, Davey Shafik wrote:
>=20
>> My main struggle with this is readability. As much as I want custom=20=

>> types (and type aliases is a good chunk of the way there), the main=20=

>> issue I have is understanding what the valid inputs are:
>>=20
>> <snip>
>=20
> Methods on typedefs was the sort of "other stuff classes do" that I =
was trying to avoid getting into right now. :-)  Mainly because I can =
totally see how it's tempting, but also have no idea what it would mean =
from a type-theoretic perspective.  It would only make sense if we're =
talking type DEFs, not type ALIASes.  I'm not against that, and it could =
be fun to try and think through the type theoretical implications, but I =
don't think that's what Rob was going for so I didn't want to take that =
side quest just yet.  (Though if he's OK with it, I'm OK with it.)

I 100% agree, but I think type DEFs are something we need to consider =
before implementing ALIASes so that we don=E2=80=99t block one with the =
other.

>=20
>> So, with that in mind=E2=80=A6 I=E2=80=99d also like to open up the =
ability for Enums=20
>> to be fulfilled by the backed value, that is:
>=20
> This is
>=20
> 1. Off topic for type aliases.
> 2. Has been discussed numerous times before.  Enums are not equivalent =
to their backing value.  The backing value is a =
standardized-serialization value.  Nothing more.  A string-backed enum =
is not a string, and a string is not a string-backed enum.  Trying to =
use an enum as transparently equivalent to its backing value is a =
categorical error and belies a misunderstanding of what Enums are.

1. It=E2=80=99s on-topic insofar as it=E2=80=99s a potential option for =
a type hint, and therefore could cause confusion
2. I _do_ understand this, but I also see that what will happen is a =
million instances of:

typealias StatusValue: Status|string;

function (StatusValue $status): void {=20
     $status =3D is_string($status) ? Status::tryFrom($status) : =
$status;
}

Possibly with a try/catch around it too if you want a custom exception =
to be thrown.

And yes, I know you can just do this today:

function (Status|string $status): void {=20
     $status =3D is_string($status) ? Status::tryFrom($status) : =
$status;
}

In reality, if we have type DEFs, we=E2=80=99ll probably see a typedef =
for every backed enum that encapsulates this behavior, so why not just =
allow it on the enum itself?

My point is that if you talk about type DEFs, you now have this feature =
where you can input one type and get something that encapsulates it, and =
it seems weird that enums would LOOK similar In type hint usage and =
function differently.

Again, I=E2=80=99m mostly concerned about the cognitive overhead of type =
ALIASes AND type DEFs if they indistinguishable from classes and enums =
when looking at a function signature and trying to call it without the =
assistant of advanced auto-complete. At the very least,
It should be clear that there is somewhere else I have to look to =
understand what the possible inputs are, and would like to again point =
to the possibility of distinguishing the use of type ALIASes (and/or =
DEFs) in type hints:

public *StatusValue $status;

function (*StatusValue $status): *StatusValue { }

etc.

- Davey=