Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102547
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.170 as permitted sender)
MIME-Version: 1.0
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>
In-Reply-To: <CAF+90c-r0w9C89sFh5+MiobyWKELkWWi0+3-UWVq7yqtk_q4_Q@mail.gmail.com>
Date: Sun, 1 Jul 2018 13:21:04 -0300
Message-ID: <CAP=4hCJjpc3vKaHv=vWcd_G-4VMJsPCTjrPaesO9JX6TSysn2w@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Sara Golemon <pollita@php.net>, Stanislav Malyshev <smalyshev@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000316252056ff278a4"
Subject: Re: [PHP-DEV] [RFC] Mixed type
From: carusogabriel34@gmail.com (Gabriel Caruso)

--000000000000316252056ff278a4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> >> 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 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 o=
f
> 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
>


Hello Nikita, Sara, Stan

I agree with you that mixed in our current type system would be missused by
those that want to document more than one type. So, the best to do would be
to wait for a `union type` system in PHP, and than merge this feature to
really document that a function accepts anything?

Thanks,
--=20
Gabriel Caruso

--000000000000316252056ff278a4--