Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101372
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAO7eTqNQ5T7=9pYC_q35ETnBDzNwEeSjvuvvv_uy3+LmEjcovw@mail.gmail.com>
References: <CAO7eTqNQ5T7=9pYC_q35ETnBDzNwEeSjvuvvv_uy3+LmEjcovw@mail.gmail.com>
Date: Mon, 18 Dec 2017 22:44:59 -0500
Message-ID: <CAEUnE0dGyo9Q69KVLef0XH4aA3x+yTxwJh5m94Bm8ODerC2R8w@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="94eb2c1289ba8bbcdd0560a94a27"
Subject: Re: [PHP-DEV] [RFC] Mixed Typehint
From: tendoaki@gmail.com (Michael Morris)

--94eb2c1289ba8bbcdd0560a94a27
Content-Type: text/plain; charset="UTF-8"

On Mon, Dec 18, 2017 at 10:34 PM, Michael Moravec <php.net@majkl578.cz>
wrote:

> Hello internals,
>
> I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3:
> https://wiki.php.net/rfc/mixed-typehint
>
> The purpose of this RFC is to introduce "mixed" typehint on language level
> to be used
> as a valid typehint.


If I'm not mistaken, "mixed" is used in documentation when a function has
been overloaded to avoid needing to have documentation for all the methods.
C allows overloading, and I imagine that PHP functions implemented in the
engine using C are using overloading.

To be honest, I'd rather see function overloading in PHP than this, but
that's a massive can of worms with a lot of problems on both the
implementation side and also on the usage side. Function overloading can be
abused to create some rather bizarre and difficult to follow code.  That
said, with PHP moving to be at least a little more strict about variable
types.

As to the proposal itself, I see no advantage over not using a typehint at
all.

More on overloading: https://en.wikipedia.org/wiki/Function_overloading

--94eb2c1289ba8bbcdd0560a94a27--