Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125249
Message-ID: <28f8e671-c42c-4259-9b1d-b93795168fe9@varteg.nz>
Date: Mon, 26 Aug 2024 13:09:37 +1200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] State of Generics and Collections
To: internals@lists.php.net
References: <1b59392a-68cb-36eb-0fef-977ac7113520@php.net>
 <68b2f0c0-17e5-4aa4-8706-92f05aca2a95@app.fastmail.com>
Content-Language: en-GB
In-Reply-To: <68b2f0c0-17e5-4aa4-8706-92f05aca2a95@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: weedpacket@varteg.nz (Morgan)

To throw one more question into the pot, I'd like to raise the 
possibility of wanting typedefs. (To use the old C/C++ term, the latter 
also allows a "type alias" syntax that does much the same thing.)

To use an example from the blog post:

function f(List<Entry<int,BlogPost>> $entries): Map<int, BlogPost>
{...}

there need not be an explicit `Map` class; instead something like

`type Map<X,Y> = List<Entry<X,Y>>;`

(to use Rust syntax).

So that one could write `Map<int,BlogPost>` and have it *mean* 
`List<Entry<int,BlogPost>>`. The blog example constructed a new Map 
given the List of Entries, but with the alias that would become a no-op.

Meanwhile `BlogPost` might itself be an alias for 
`StructuredText<\DomDocument>`. Without the aliasing therefore we're 
looking at `List<Entry<int,StructuredText<\DomDocument>>` and who is 
going to write that over and over? It would muffle use of generics.

I seem to recall that C#'s (or was it Java?) early support of generics 
didn't offer any sort of abbreviation mechanism and this lead to long 
awkward concrete types that no-one wanted to use.

Calling them "aliases" implies that they're expanded before types are 
matched up. If `Wibble<string>` and `Splunge<int>` both ultimately 
expand to `Foo<Bar<int>,Baz<string>>` then they would be considered to 
be the same type, despite appearances.

Since I expect that type aliases would become a desired feature, I would 
hesitate to allow/disallow making type inferences that could block their 
introduction. While the alias resolution would be an early stage that 
does mean it has to be able to identify any uses of a type in order to 
check whether it is a type alias. I can't think of any specific examples 
where this would be a problem, but it depends on how they actually end 
up looking - they should look like types.