On Mon, Sep 9, 2024, at 4:35 PM, Rowan Tommins [IMSoP] wrote:
> On 09/09/2024 19:41, Mike Schinkel wrote:
>
>> Referencing prior art (e.g. Go) PHP could allow int literals — e.g. `1`,
>> `47`, etc. — to be passed to typedefs derived from ints but require int
>> variables to be typecast to the required type. Same for string literals.
>
> That's an interesting compromise, worth considering.
I have concerns about this. Mainly, it depends on what we would want a typeef
to *do*. Eg, if it's just an alternate name, then maybe. If, however,
typedefs allow other functionality -- such as validation, additional methods,
etc. -- then primitive -> typeef is not a guaranteed total function. Eg;
typedef UserId: string is /\s{3}-\s{4}/ {
public function groupId(): string {
return substr($this, 3);
}
}
Maybe that particular functionality makes sense to do, maybe not, that's a
separate discussion. My point for now is just that there are typedef
approaches where auto-up-casting would be frequently invalid, and probably also
designs where auto-down-casting would be invalid (or possibly valid). For now,
we should keep all options on the table until we decide which options we want
to make impossible.
>> In Go you cannot add or subtract on a typedef without casting to the
>> underlying type. I would definitely prefer that to be relaxed, but only
>> if it is relaxed via an explicit opt-in, e.g. something maybe like
>> this:
>>
>> typedef UserId: int operations: +, -, *, /;
>> typedef UserName: string operations: .;
Not to go further down this rabbit hole than is necessary, but I would much
rather see operator overloads adopted, along the lines of Jordan's previous
RFC, and let typedefs implement that if them if sensible.
There's probably yet another research project to do here. I'd volunteer, but I
now have a newborn taking up most of my time. :-)
--Larry Garfield
