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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to