Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121475
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1048-g9229b632c5-fm-20231019.001-g9229b632
MIME-Version: 1.0
Message-ID: <e94b0021-b18d-4c48-8764-6d4909142b26@app.fastmail.com>
In-Reply-To: 
 <CAHXoPRtjsPzgpYnhB05hjdZo6Q-MDr4TUGbn9LQ77-hKVTCZOA@mail.gmail.com>
References: 
 <CAHXoPRtjsPzgpYnhB05hjdZo6Q-MDr4TUGbn9LQ77-hKVTCZOA@mail.gmail.com>
Date: Thu, 26 Oct 2023 19:23:18 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Basic Type Alias
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Oct 26, 2023, at 6:37 AM, Oladoyinbo Vincent wrote:
> Greetings to you all,
>
> I will like to submit an RFC on introducing type alias to php.
>
> Even though Generics won't or never be introduced to PHP, personally i will
> like php to add the type alias feature.
>
> Type aliases provide a mechanism to create more descriptive and readable
> type hints in PHP code. This enhancement will improve code readability and
> maintainability and also to promote type reusability.
>
>
> Motivation:
>
> The motivation behind introducing type aliases is to:
>
> 1. Enhance code readability by allowing developers to use meaningful type
> hint names.
> 2. Improve code maintainability by reducing the likelihood of type hint
> updates throughout the codebase.
> 3. Encourage the adoption of best practices for type hinting.
>
>
> Proposal:
>
> Syntax:
>
> Type aliases will be declared using the `type` or `typealias` keyword,
> followed by the alias name, an equal sign (`=`), and the type it is aliased
> to.
>
>
> Sample:
>
> ```
> type MyType = string;
>
> // or
>
> typealias MyType = string;
>
>
> // Advance
>
> type MyType = string|null;
>
> // or
>
> type MyType = [string, null];

What would this one even do?

Type aliases have been discussed several times in the past, and a lot of people are strongly in favor, myself included.  They are arguably a prerequisite for callable types.  (Or rather, the people who want to work on callable types refuse to until we get type aliases. :-) )

The complication is, as some other replies noted, their scope.

File local type aliases would be pretty easy:

```
use type int|float as numeric;

function add(numeric $a, numeric $b): numeric {}
```

However, that's also not all that useful.  A library that uses some complex type (such as a callable type) could not provide a reusable and standardized alias for it, which means everyone would have to re-declare it themselves in every file that uses it, and would probably all use different names (numeric, number, num, etc.), making it all very confusing.

App-wide aliases run into the autoloading problem.  If the engine runs across the add() function above, and "numeric" isn't defined, what can it do?  Currently, all it can do is trigger autoloading, which only works for class-ish constructs (class, interface, trait, enum).  Making type aliases a full class-like construct seems... weird, and over-engineered.  But if not, how do we autoload them?  And if they do autoload somehow, does that mean we end up with a bunch of files with a single `type` line in them?  That seems not-good.  You also then have to ask how they interact with namespaces.

So far no one seems to like my idea of "composer has a files block, PHP has a preloader, they're small, so who the hell cares about autoloading, just greedily load them and move on with life", even though I think that's the best answer. :-)

So any type alias proposal would need to sort out the above "definition problem" in a way that's generally acceptable.  That's been the hold up for 3 years, I think.

I'm also not sure why you're mentioning generics at all.  Type aliases would be helpful with generics, but they're also helpful without generics.  They're orthogonal and not especially related.  I agree that there's no reason to wait for generics to add type aliases.

--Larry Garfield