Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102540
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.208.50 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <854a8dfc-4bc1-c001-a1a7-5347e5483ac8@gmail.com>
References: <CAP=4hCL0XtR_bv4fYY3o8gPPHknVK6p14rGkAaXgeS2xjaLbbg@mail.gmail.com>
 <854a8dfc-4bc1-c001-a1a7-5347e5483ac8@gmail.com>
Date: Sat, 30 Jun 2018 15:17:17 -0500
Message-ID: <CAESVnVoB+NuUJQPpoUq6=FZKdspxO=zkYr8H4DTeoob5+Pf21g@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Gabriel Caruso <carusogabriel34@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Mixed type
From: pollita@php.net (Sara Golemon)

On Sat, Jun 30, 2018 at 3:08 PM, Stanislav Malyshev <smalyshev@gmail.com> w=
rote:
>> Together with Michael Moravec, we=E2=80=99d like to announce that we are=
 pretending
>> to open the Mixed Type RFC (https://wiki.php.net/rfc/mixed-typehint) nex=
t
>> Monday (02/07) and we=E2=80=99d like to ask you to take a look into the =
PR on
>> GitHub (https://github.com/php/php-src/pull/2603) and let us know if
>> there's something else to do before it.
>
> I think this is wrong. This "type" - which is not really a type, of
> course - does not add anything to the code, by definition - if you take
> it out, everything would be the same. Things like that belong in the
> documentation. Moreover, it makes the code harder to read, as the reader
> should make mental effort to discard this non-type every time it is
> mentioned, as it does not carry any information.
>
I would say that, in a world without union or intersection types, it
adds to the readability of the code by explicitly saying, "We accept
more than one type here, and we know we accept more than one type
here." This is distinct from, "We have no idea what type we accept
here."  That adds to readability, it doesn't detract.

I preface that with a mention of union/intersection types because that
seems to be the *actual* problem this RFC is attempting to cope with
while lacking the tools to do it right.  I'm not super excited about
this RFC because, as you say, this information could be easily encoded
into the docblock for the function/method.  Zero impact to the syntax,
same benefit for the programmer and their readability. (More benefit,
really, as docblock standards *do* permit union/intersection types.

So, complex types maybe?

-Sara