On Fri, Sep 30, 2022, at 4:04 AM, Olle Härstedt wrote:
> 2022-09-29 5:08 GMT+02:00, Hamza Ahmad <office.hamzaah...@gmail.com>:
>> Hi Olle,
>>
>> I appreciate your idea of introducing a similar concept of typedef.
>> What if you write an RFC explaining that concept. I can join you
>> however in co-authoring this request.
>>
>> Seriously, I have had issues with writing such type again and again.
>> If you look at mixed type, it is indeed an alias of some union types.
>> Adding such an option to userland would lead to introduction of
>> various type hints. Plus, it will help devs write short hand aliases
>> for their intersection types.
>
> Note that my suggestion here is NOT about a project-global type alias,
> but an extension of the existing file-only alias, the use-statement.
> This can also explain the lack of reaction. :) Internal devs might
> already have consensus on the right way to proceed here, even if
> there's no RFC yet.
Background:
Type aliases have been discussed several times. There's definitely interest,
but like many things it runs into the problems of time and figuring out the
details.
In particular, I don't get the sense that there's much appetite for file-local
aliases. While that would have some benefit, it could lead to all kinds of
confusion when then using code from another file. Consider:
A.php:
use int|float as number;
interface A
{
public function a(number $a) {}
}
B.php:
// Yeah, aliasing this is very helpful.
use (Request&Linkable)|(ServerRequest&Linkable)|array|null as input;
interface B
{
public function b(input $b) {}
}
C.php:
class C implements A, B
{
// Which of these to use?
public function a(int|float $a) {}
public function a(number $a) {}
// Or do I need to repeat the definition of "number" in every file?
// WTF do I do here? Do I have to repeat the entire definition either
// inline or in this file's "use" block? Both suck.
public function b(...)
}
This becomes even more of an issue when you start talking about function types,
which is often mentioned as the primary use case.
type fn(int $a, string $b): Request as mycallback
function do(mycallback $callback) {}
So I have to duplicate the type def in every file now? This is not an
improvement.
So we have to go with app-global aliases, but then... how do you handle
resolution? Autoloading? Namespacing? Conflict resolution? I dunno, that's
all hard, and that's where the conversation usually peters out.
The degenerate case you mention of simple type renaming has its own interesting
implications, which are also a factor for the broader case. Specifically, does
that create a new type unto itself, or does the difference get elided at
compile time? For instance:
use int as userId;
use int as productId;
function a(userId $user) {
b($userId);
}
function b(productId $product) {
// ...
}
a(123);
Does this work? Is it a compile error for mismatched types (as in Go, which
has this exact feature) or no? If it is, how do you make it work? Do you need
explicit casts? If it does work, have you gained much since it's no more
useful than docblocks? If it does work, how long before SA tools turn it into
an error anyway and make everything more complicated? (Because you know they
will.)
Does the same answer apply for longer type aliases like the nutty ones in the
earlier examples?
These are the kinds of questions that need to be answered before any serious
RFC could be attempted. Answers for them can certainly be found, but so far no
one has really done the work, in particular around how to make aliases cleanly
global. If you're interested in tackling that, fantastic; I think most people
would be on board with it (especially for function types). But be aware it's a
not-small puddle you're wading into.
(I think Danack had a writeup similar to this but it went a bit further; not
sure where it is off hand, but he probably knows.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
