> On Sep 6, 2024, at 16:40, Rob Landers <[email protected]> wrote:
>
>
>
> On Sat, Sep 7, 2024, at 01:34, Larry Garfield wrote:
>> On Fri, Sep 6, 2024, at 6:27 PM, Rob Landers wrote:
>>
>> >> I suspect there's also other edge case bits to worry about, particularly
>> >> if trying to combine a complex alias with a complex type, which could
>> >> lead to violating the DNF rule. For example:
>> >
>> > Oh, DNF is the bane of my existence with this RFC—I don't want to mess
>> > this up. I'll see you at the end of the example, though.
>> >
>> >>
>> >> typealias Foo: (Bar&Baz)|Beep;
>> >>
>> >> use (Bar&Baz)|Beep as Foo;
>> >>
>> >> function narf(Foo&Stringable $s) {}
>> >>
>> >> With the compile time approach, that would expand to
>> >> `(Bar&Baz)|Beep&Stringable`, which is not a valid type def.
>> >
>> > I can see how you arrived at this, but I think you may have missed a
>> > step, since the entirety of Foo will be &'d with Stringable.
>> >
>> > Foo = (Bar & Baz) | Beep
>> >
>> > want: (Foo) & Stringable
>> >
>> > expand Foo: ((Bar & Baz) | Beep) & Stringable
>> >
>> > Which can be reduced to the following in proper DNF (at least, it
>> > compiles—https://3v4l.org/0bMlP):
>> >
>> > (Beep & Stringable) | (Bar & Baz & Stringable)
>> >
>> > It's probably a good idea to update the RFC explaining how expansion works.
>>
>> Woof. We're not "fixingup" anyone's DNF elsewhere. I cannot speak for
>> everyone, but I'd be perfectly fine not doing any magic fixing for now, and
>> then debating separately if we should do it more generally. Just doing it
>> for aliases doesn't seem like the best plan.
>>
>> --Larry Garfield
>>
>
> Oh, we're definitely not "fixingup" the expression to DNF... more like
> spending some time in the RFC showing how the expansion is the same execution
> as with a DNF expression to prove that it is a valid type expression.
>
> — Rob
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:
function foo(Status $string): void { }
How do I know that Status is a) not a class, b) that I can fulfill the
requirement with a string, and/or maybe any object with __toString(), or maybe
it’s ints? Or objects or enums?
Even with file-local aliases (which I would definitely prefer to avoid) we will
most likely rely on developer tooling (e.g. IDEs and static analyzers) to
inform the developer what the right input types are.
I would very much prefer to either go all in with an Enum-like (which means
that we can hang methods on to the value) or we need to distinguish between
type hints for class-likes and type hints for not-class-likes (*Bar anyone?).
Expanding on type-class-likes: within the type methods, $this->value would
refer to the original value, any operators would follow the _same_ rules as
either the original values type (e.g. $int = 4; $string = “foo”; $int .
$string == “4foo", or call __toString() in all the normal places for strings if
defined).
type Stringable: string|int {
public function __toString(): string
{
return (string) $this->value; // original value
}
// Add Stringable methods here
}.
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:
function foo(Bar $bar): void { }
Where Bar is:
enum Bar: string {
case BAZ = 'baz';
case BAT = ‘bat';
}
And you can call `foo()` like: foo(‘baz’) and Bar::BAZ will be passed in.
I realize I’m opening a barn down here, but I just don’t see file-local type
aliases as that useful, and while I like the functionality of type-class-likes,
I think they would add more non-class behavior (in addition to enums) for
things that look like classes if we don’t add some sort of identifier. I’d much
rather that we add backed-value to enum casting, and at least make that more
consistent with this functionality if we’re going to conflate the syntax.
- Davey
