Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125474
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 07 Sep 2024 15:36:44 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <63d241a8-a34a-498c-a5f9-f34230aa5afa@app.fastmail.com>
In-Reply-To: <D95D21CE-45AB-487A-B59D-40305C0C569D@rwec.co.uk>
References: <0fa39535-f22d-4eba-b4df-90abe39e683a@app.fastmail.com>
 <e73be2b0-faa9-42eb-a9f6-8308cf4f8c94@app.fastmail.com>
 <ed3847bf-af2e-4e33-ac09-66e44696fdeb@app.fastmail.com>
 <79e58673-50ec-461e-a998-736b020e4287@app.fastmail.com>
 <a3cd6d90-cfac-40d5-a59a-c9f6d9dbe5f0@app.fastmail.com>
 <928A2984-6035-4DA6-9EA7-12E85237C270@php.net>
 <0d461700-1b6c-44fd-9cda-aa698de49847@app.fastmail.com>
 <667233C2-BC47-4530-8142-D90E6907FE63@daveyshafik.com>
 <D95D21CE-45AB-487A-B59D-40305C0C569D@rwec.co.uk>
Subject: Re: [PHP-DEV] bikeshed: Typed Aliases
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Sep 7, 2024, at 12:07 PM, Rowan Tommins [IMSoP] wrote:
> On 7 September 2024 17:23:13 BST, Davey Shafik <me@daveyshafik.com> 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