Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125468
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 07 Sep 2024 08:28:04 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <0d461700-1b6c-44fd-9cda-aa698de49847@app.fastmail.com>
In-Reply-To: <928A2984-6035-4DA6-9EA7-12E85237C270@php.net>
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>
Subject: Re: [PHP-DEV] bikeshed: Typed Aliases
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Sep 6, 2024, at 7:46 PM, Davey Shafik wrote:

> 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:
>
> function foo(Status $string): void { }
>
> How do I know that Status is a) not a class, b) that I can fulfill the=20
> requirement with a string, and/or maybe any object with __toString(),=20
> or maybe it=E2=80=99s ints? Or objects or enums?
>
> Even with file-local aliases (which I would definitely prefer to avoid=
)=20
> we will most likely rely on developer tooling (e.g. IDEs and static=20
> analyzers) to inform the developer what the right input types are.
>
> I would very much prefer to either go all in with an Enum-like (which=20
> means that we can hang methods on to the value) or we need to=20
> distinguish between type hints for class-likes and type hints for=20
> not-class-likes (*Bar anyone?).
>
> Expanding on type-class-likes: within the type methods, $this->value=20
> would refer to the original value, any operators would follow the=20
> _same_ rules as either the original values type (e.g. $int =3D 4; $str=
ing=20
>  =3D =E2=80=9Cfoo=E2=80=9D; $int . $string =3D=3D =E2=80=9C4foo", or c=
all __toString() in all the=20
> normal places for strings if defined).
>
>
> type Stringable: string|int {
>      public function __toString(): string
>      {
>           return (string) $this->value; // original value
>      }
>
>      // Add Stringable methods here
> }.

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 totall=
y 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 q=
uest just yet.  (Though if he's OK with it, I'm OK with it.)

> So, with that in mind=E2=80=A6 I=E2=80=99d also like to open up the ab=
ility for Enums=20
> to be fulfilled by the backed value, that is:

This is

1. Off topic for type aliases.
2. Has been discussed numerous times before.  Enums are not equivalent t=
o their backing value.  The backing value is a standardized-serializatio=
n value.  Nothing more.  A string-backed enum is not a string, and a str=
ing 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 mis=
understanding of what Enums are.

cf: https://peakd.com/hive-168588/@crell/on-the-use-of-enums

--Larry Garfield