Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101421
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain heigl.org designates 195.191.240.18 as permitted sender)
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Tue, 26 Dec 2017 16:59:08 +0100
Message-ID: <88921EA7-EB68-4630-AA9E-DE0C04342F0B@heigl.org>
References: <72392123-d37b-26df-6886-218f48205f8a@fleshgrinder.com> <5171148a-3554-35a3-ab72-370e1aac4a3f@php.net>
In-Reply-To: <5171148a-3554-35a3-ab72-370e1aac4a3f@php.net>
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
From: andreas@heigl.org (Andreas Heigl)

Hey All.=20

> Am 26.12.2017 um 14:38 schrieb Sebastian Bergmann <sebastian@php.net>:
>=20
>> Am 24.12.2017 um 15:34 schrieb Fleshgrinder:
>> I prepared a PR to add the `scalar` pseudo-type to PHP after the
>> discussions around adding a `mixed` pseudo-type. I strongly believe that
>> it makes sense to provide the most common primitive union types with
>> handy aliases even if we are going to add union types in the future to PH=
P.
>=20
> Thank you, Richard, for working on this.
>=20
> I spent a lot of time this year introducing scalar type declarations into
> existing code bases. In quite a few cases I was not able to do so because
> the existing code works with parameters that can be of two or more scalar
> types. With PHP 7.2, I can only document this outside of the code using
> @param annotations (until the code has been refactored to work with only
> one parameter type).
>=20
> With a "scalar" type declaration I would not have to fall back to @param
> annotations and could express the type in actual syntax.

Just a stupid question from someone that isn't following all the discussions=
 here. So forgive me if the question was already asked and answered.=20

What would be wrong with a "composed type hint"? Something like int|float|do=
uble $numeric. Or array|Traversable $iterator?=20

It would allow people to add "mixed" typehints without having to introduce m=
ultiple typehints that combine different scalar typehints. And it could even=
 allow typehinting different Objects in one function.=20

Yes, it allows people to shoot themselfes into their own feet.=20

And I'd only allow that for parameter types and never ever for return types.=
=20

But it might be an idea.=20

Cheers

Andreas=20