Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102542
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.194 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVoB+NuUJQPpoUq6=FZKdspxO=zkYr8H4DTeoob5+Pf21g@mail.gmail.com>
References: <CAP=4hCL0XtR_bv4fYY3o8gPPHknVK6p14rGkAaXgeS2xjaLbbg@mail.gmail.com>
 <854a8dfc-4bc1-c001-a1a7-5347e5483ac8@gmail.com> <CAESVnVoB+NuUJQPpoUq6=FZKdspxO=zkYr8H4DTeoob5+Pf21g@mail.gmail.com>
Date: Sat, 30 Jun 2018 22:30:40 +0200
Message-ID: <CAF+90c-r0w9C89sFh5+MiobyWKELkWWi0+3-UWVq7yqtk_q4_Q@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, Gabriel Caruso <carusogabriel34@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000087e30e056fe1d69b"
Subject: Re: [PHP-DEV] [RFC] Mixed type
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000087e30e056fe1d69b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 30, 2018 at 10:17 PM, Sara Golemon <pollita@php.net> wrote:

> On Sat, Jun 30, 2018 at 3:08 PM, Stanislav Malyshev <smalyshev@gmail.com>
> wrote:
> >> Together with Michael Moravec, we=E2=80=99d like to announce that we a=
re
> pretending
> >> to open the Mixed Type RFC (https://wiki.php.net/rfc/mixed-typehint)
> next
> >> Monday (02/07) and we=E2=80=99d like to ask you to take a look into th=
e 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 reade=
r
> > 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.
>

I'm basically with Sara here. Generally the feature has some merit, but I'm
sure that given our current type-system, and in particular the lack of
union types, this feature will be misused to annotate parameters that do
*not* accept completely arbitrary values, but where "mixed" is the best
approximation we have. For that reason I would prefer to defer this
addition until proper union types are supported. In that case mixed would
be a shortcut for the otherwise somewhat unwieldy type of
?(bool|int|float|string|array|object|resource) (modulo the non-existence of
resource...)

Nikita

--00000000000087e30e056fe1d69b--