> On Sep 7, 2024, at 06:28, Larry Garfield <la...@garfieldtech.com> 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
