On Sat, Sep 7, 2024, at 12:07 PM, Rowan Tommins [IMSoP] wrote:
> On 7 September 2024 17:23:13 BST, Davey Shafik <[email protected]> wrote:
>>
>>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.
>
> Personally, I would prefer to go the other way: make typedefs, like
> enums, something you explicitly construct / cast to, rather than
> something that implicitly coerces any compatible value.
>
> Like enums, I would want to use typedefs to prevent accidental mixing
> of values (e.g. a name where a reference number was expected, or a size
> in pixels where a size in centimetres was expected). That use is
> compromised if every scalar value is silently accepted for any matching
> typedef.
>
> Regards,
> Rowan Tommins
> [IMSoP]
There's a couple of different use cases floating around close to each other
here.
One is a type *alias*, which is just "a way to type less."
The other is a type *def*, which creates a new for-reals type that you can
check at runtime.
They are closely related, but serve different purposes. While an alias could
make sense file-local or app-wide, in practice a def only makes sense app-wide.
Whether we want to have one or the other or both is a subjective question.
Personally I'd be fine with both, as I see them serving different purposes.
eg:
typealias Foo: Bar|Baz;
Foo is now a compile time copy-paste for Bar|Baz, meaning this is totally valid:
class A {
public Foo $a;
}
class B {
public Bar|Baz $a;
}
The other direction is:
typedef UserId: int;
UserID is now an object that consists of just an int, but can be type checked
against. What's unclear is if you can do other int-y things to them (add,
subtract, etc.), or if it's really just a shorthand for
readonly class UserId {
public function __construct(public int $value) {}
}
I could see an argument for either. If we had operator overloads, I would
absolutely go for the latter; make all of those other int-y things opt-in.
Once we get pattern matching, as noted a few months ago, it could be quite
powerful to allow patterns as a validation on a typedef of that sort.
typedef UserId: int is >0;
Though that opens up all kinds of interesting questions about a typedef based
on another typedef, if that's a form of inheritance or not, etc. Again, I'm
not sure if Rob wants to go there or not, but it's a place my brain has gone
before. :-)
We may want to focus just on aliases for now, but design them in such a way
that they do not cause an issue for typedefs in the future. (Eg, using the
`typealias` keyword instead of just `type`.)
--Larry Garfield
