Re: [RFC] [Under Discussion] Auto-implement Stringable for string backed enums

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 typo 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 > constants are the right solution to to this. > > What users want is some way to say "this value should be a string, but > in this context it should be one of this list of strings"; or, > sometimes, "is this string one of this list of strings?" Constants can't > do that - they give you a way of referring to the possible values, but > no tools for enforcing or testing against them. Backed enums can kinda > sorta do that with a bit of effort, using ->value and ::tryFrom, but > they're not really built for it. > > > A better fit would be some kind of "domain type", which would allow you > 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, > and maybe even calculate intersections, unions, etc: > > assert( is_subset(AcmePermission, SymfonyPermission) ); > > > The actual values would be ordinary strings, and type constraints would > just be checking the value passed against the domain: > > function doSymfonyThing(SymfonyPermission $permission) { >     echo $permission; // no coercion needed, $permission is a string > } > > function doAcmeThing(AcmePermission $permission) { >     doSymfonyThing($permission); > } > > doAcmeThing('admin'); // no special syntax needed to "construct" or > "look up" an instance > > > Crucially, this solves the described problem of a library accepting an > infinite (or perhaps just very wide) set of values, and a consuming app > wanting to constrain that set within its own code. > > It's one disadvantage is the typo-proofing and look up availability that > constants give, but you could always combine the two. Interesting concept. I'm not sure if I like it yet, but it's interesting. :-) 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 like the sort of thing some mathematician has likely thought through for funsies before. --Larry Garfield