Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102548
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.160.51 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAF+90c-r0w9C89sFh5+MiobyWKELkWWi0+3-UWVq7yqtk_q4_Q@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>
 <CAF+90c-r0w9C89sFh5+MiobyWKELkWWi0+3-UWVq7yqtk_q4_Q@mail.gmail.com>
Date: Sun, 1 Jul 2018 19:26:55 +0200
Message-ID: <CADqTB_gM4hH4_HLE=8SJJpim-2wJHApLcJgN=thxEoZiAQbbFA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Sara Golemon <pollita@php.net>, Stanislav Malyshev <smalyshev@gmail.com>, 
	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: rasmus@mindplay.dk (Rasmus Schultz)

Nikita,

I think we'll need the mixed type-hint in any case if we're to move
ahead with generics?



On Sat, Jun 30, 2018 at 10:30 PM, Nikita Popov <nikita.ppv@gmail.com> wrote=
:
> 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 =
are
>> 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 t=
he 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 tak=
e
>> > it out, everything would be the same. Things like that belong in the
>> > documentation. Moreover, it makes the code harder to read, as the read=
er
>> > 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