Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118075
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-713-g1f035dc716-fm-20220617.001-g1f035dc7
Mime-Version: 1.0
Message-ID: <7f5cb2ca-8104-4c46-a4b5-fd15dbc10ff8@www.fastmail.com>
In-Reply-To: <616fe4af-4945-82cf-c1e5-aa52535bf1f8@gmail.com>
References: 
 <CAOWwgpmG33Ybp6KS4ePrMgMJdW5xX+M2mos2cpgoVNUy8dVMjQ@mail.gmail.com>
 <9C11261B-B9D0-4342-81EB-60276B3036E5@php.net>
 <2cee17c0-7b77-4709-94b9-598a4c3d1f49@www.fastmail.com>
 <616fe4af-4945-82cf-c1e5-aa52535bf1f8@gmail.com>
Date: Thu, 23 Jun 2022 10:35:49 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] Auto-implement Stringable for string
 backed enums
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Jun 22, 2022, at 4:43 PM, Rowan Tommins wrote:
> On 22/06/2022 18:26, Larry Garfield wrote:
>> The argument presented is that it's easier to type `AppRoles::Admin` =
than `"admin"`, because the former provides you with an error if you typ=
o something.  That's a valid argument, but... not for using enums.  It's=
 an argument for using constants.
>
>
> I wonder if the reality is that neither enums (as implemented) nor=20
> constants are the right solution to to this.
>
> What users want is some way to say "this value should be a string, but=20
> in this context it should be one of this list of strings"; or,=20
> sometimes, "is this string one of this list of strings?" Constants can=
't=20
> do that - they give you a way of referring to the possible values, but=20
> no tools for enforcing or testing against them. Backed enums can kinda=20
> sorta do that with a bit of effort, using ->value and ::tryFrom, but=20
> they're not really built for it.
>
>
> A better fit would be some kind of "domain type", which would allow yo=
u=20
> to write something vaguely like this:
>
> domain SymfonyPermission: string;
> domain AcmePermission: string { 'admin' | 'user' | 'bot' };
>
> assert( in_domain('admin', SymfonyPermission) );
> assert( in_domain('admin', AcmePermission) );
>
> assert( in_domain('random stranger', SymfonyPermission) );
> assert( ! in_domain('random stranger', AcmePermission) );
>
>
> Domains can also be considered sets, which you could compare directly,=20
> and maybe even calculate intersections, unions, etc:
>
> assert( is_subset(AcmePermission, SymfonyPermission) );
>
>
> The actual values would be ordinary strings, and type constraints woul=
d=20
> just be checking the value passed against the domain:
>
> function doSymfonyThing(SymfonyPermission $permission) {
>  =C2=A0=C2=A0=C2=A0 echo $permission; // no coercion needed, $permissi=
on is a string
> }
>
> function doAcmeThing(AcmePermission $permission) {
>  =C2=A0=C2=A0=C2=A0 doSymfonyThing($permission);
> }
>
> doAcmeThing('admin'); // no special syntax needed to "construct" or=20
> "look up" an instance
>
>
> Crucially, this solves the described problem of a library accepting an=20
> infinite (or perhaps just very wide) set of values, and a consuming ap=
p=20
> wanting to constrain that set within its own code.
>
> It's one disadvantage is the typo-proofing and look up availability th=
at=20
> constants give, but you could always combine the two.

Interesting concept.  I'm not sure if I like it yet, but it's interestin=
g. :-)  It somehow feels related to Go's type aliasing, but I'm not sure=
 if that's a fair comparison.

Is there a type-theoretic basis we could look at for that?  It seems lik=
e the sort of thing some mathematician has likely thought through for fu=
nsies before.

--Larry Garfield