> On Sep 7, 2024, at 06:28, Larry Garfield <[email protected]> wrote:
>
> 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
>> types (and type aliases is a good chunk of the way there), the main
>> issue I have is understanding what the valid inputs are:
>>
>> <snip>
>
> 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’t block one with the other.
>
>> So, with that in mind… I’d also like to open up the ability for Enums
>> 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 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’s on-topic insofar as it’s 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 {
$status = 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 {
$status = is_string($status) ? Status::tryFrom($status) : $status;
}
In reality, if we have type DEFs, we’ll 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’m 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