Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118720
MIME-Version: 1.0
In-Reply-To: <CAJpLVh3Sxh0Ca=F-NxODcxrYJKaVT1DoKtMcaMopWtx3HcVZ7g@mail.gmail.com>
References: <CAJpLVh2y1SKiuNzbqNC=RrNUjKaLGMNfy4VjE-92q8LgWOqTsg@mail.gmail.com>
 <CAC_PL4wGQCWE8S_eO2PqskSuL=P0xEzUou0F=AfThwStMPWrdw@mail.gmail.com>
 <CAJpLVh0jRgGsC83D80r-JzmnTjhAjr_K9EaqxYorHirNrTLJ6Q@mail.gmail.com>
 <38350298-6aaa-4739-b927-0a9423baae4e@app.fastmail.com> <CAJpLVh3Sxh0Ca=F-NxODcxrYJKaVT1DoKtMcaMopWtx3HcVZ7g@mail.gmail.com>
Date: Sat, 1 Oct 2022 07:33:39 +0500
Message-ID: <CAC_PL4wBzz-VO78QW8qSkm9qmwqVy0h2EYwLYAF2SazEXB-ZMA@mail.gmail.com>
To: =?UTF-8?Q?Olle_H=C3=A4rstedt?= <olleharstedt@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: Alias for `int|float`
From: office.hamzaahmad@gmail.com (Hamza Ahmad)

After reading through all of the suggestions above, I have come to
this conclusion that all suggestion can be incorporated in the
following ways:
Types can exist in name spaces, Either in the global namespace or in
the user defined name spaces. If one wants to import a type from a
name space, it can easily use "use" statement per file. Alternatively,
it can include a namespace and it does all that handy job for the dev.
I agree with the idea of creating an RFC and document all use cases,
possible ways to implement and also the features that can be added
currently or will be left for the future scope.

Regards
 Ahmad

On 9/30/22, Olle H=C3=A4rstedt <olleharstedt@gmail.com> wrote:
> 2022-09-30 17:16 GMT+02:00, Larry Garfield <larry@garfieldtech.com>:
>> On Fri, Sep 30, 2022, at 4:04 AM, Olle H=C3=A4rstedt wrote:
>>> 2022-09-29 5:08 GMT+02:00, Hamza Ahmad <office.hamzaahmad@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.
>
> Ya ok, not what I could find in externals.io ^^
>
>> 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 t=
o
>> 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?
>
> Yes, you would. That's the limit of my current suggestion. Same
> semantics as use-statements.
>
>>   // 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(...)
>
> Neither suck. :) Just "normal" inheritance boilerplate in the absence
> of project-global type aliasing.
>
> Do you have similar counter-examples for non-OOP code?
>
>> }
>>
>>
>> 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.
>
> It's an improvement for readability, especially when repeated in one
> file. But my suggestion does not include function-types, because
> there's no such thing already in the system. Just to let use-statement
> include more of already existing types. If function-types were added
> later, they should be supported too, yes.
>
>>
>> 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.
>
> Yeah, always better to have a clear limitation, is it not? :D
>
>> 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
>
> No. Keep the same semantics of the current use-statement. But it could
> be a future extension, sure. But then you need some kind of "factory"
> way to produce those types. In FP they do it with "abstract types",
> where the implementation of a type is hidden from outside the module.
> In PHP, maybe with Foo::make() functions or such. Different
> discussion.
>
>> 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 n=
o
>> 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.)
>
> Not sure I agree with you there. Obviously, static analyzers would
> have to abide to the semantics of the core language, no...?
>
>> Does the same answer apply for longer type aliases like the nutty ones i=
n
>> the earlier examples?
>>
>> These are the kinds of questions that need to be answered before any
>> serious
>> RFC could be attempted.
>
> Isn't an RFC a good place to document all these cases? I was thinking
> that an RFC could be a good place even for things we do NOT want to
> implement. to help pave the way for features we do.
>
>> Answers for them can certainly be found, but so far
>> no one has really done the work, in particular around how to make aliase=
s
>> 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 never had a need for such a feature tho. :d Although my motivation
> for current concept is also dubious (transpilation to C, mainly).
> Maybe generic-notation for arrays is more relevant to improve
> type-hints, buuut that's another can of worms, and I didn't read up on
> current discussion yet. :)
>
> Thanks for the feedback, Larry! Can I still get karma to write it down
> in the wiki? Again, not to necessarily encourage implementation, more
> for documentation purpose. And I prefer to have it on the wiki, to
> keep all the docs central.
>
> Olle
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>