Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80584
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.199 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <CAPhkiZyLgfobNv_cRVvgDLfyETLYAk8dXJx6mm-D9-b2oZomWQ@mail.gmail.com>
Date: Thu, 15 Jan 2015 19:52:24 +0000
Cc: Mike Willbanks <pencap@gmail.com>,
 Zeev Suraski <zeev@zend.com>,
 Richard Quadling <RQuadling@gmail.com>,
 Leigh <leight@gmail.com>,
 PHP Internals List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <8BABA306-12CE-4568-98F3-419A1557F61B@ajf.me>
References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me> <CAPwsocGyv7dp8n=_E1QfrXRSbYZXcHZAPk5F=hDLB070i=SCGA@mail.gmail.com> <4E2073DE-0951-498C-97BB-DDAC094F11FA@ajf.me> <9a033dd1f223f854e760924d118ab812@mail.gmail.com> <CAKUjMCU-57cDpG5ZbDGv10dSqx=Ey40D-WbKxKSnC6oSYOfLWw@mail.gmail.com> <2ae0164cb9b9bf1c974d7a3c60af0466@mail.gmail.com> <F3BC55CD-38CD-42B7-AE0B-A6D34E3D3875@ajf.me> <6105ea99002e634373c09685310e26a6@mail.gmail.com> <D39D18B9-A9E5-430E-B00A-E0DE03DAFE8C@ajf.me> <CALrkBjaBgvfdqLqSPDCGfHJD7XEOTOba9yg5ttHN7V1KyFA1-w@mail.gmail.com> <A6B06BAB-F8C8-4BFC-98F5-21AD572D65A2@ajf.me> <CALrkBjbmKAiDw+UCJsnugWxChvBio5FUuuEOVcDS5FAqYNrStg@mail.gmail.com> <E81E632D-EE69-454A-86EC-31ED79EE1110@ajf.me> <CAPhkiZyLgfobNv_cRVvgDLfyETLYAk8dXJx6mm-D9-b2oZomWQ@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>,
 marcio3w@gmail.com,
 "S.A.N" <ua.san.alex@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: ajf@ajf.me (Andrea Faulds)

Hi Andrey,

> On 15 Jan 2015, at 19:20, Andrey Andreev <narf@devilix.net> wrote:
>=20
> Consider this badly designed API:
>=20
>    declare(strict_typehints=3DTRUE);
>=20
>    const MODE_APPEND =3D 0;
>    const MODE_TRUNCATE =3D 1;
>    const MODE_PREPEND =3D 2;
>=20
>    function write_file(string $path, int $mode, string $data)
>    {
>        // it's quite obvious
>    }
>=20
> Somewhere else, you forget the parameters order ...
>=20
>    declare(strict_typehints=3DFALSE);
>=20
>    $path =3D '/important/file.dat';
>    $data =3D '1 year';
>    $mode =3D MODE_APPEND;
>=20
>    write_file($path, $data, $mode);
>=20
> It's a bad example - an awful (and indeed, very much useless) API,
> combined with an absent-minded consumer. Yet, it demonstrates how
> putting the caller in control *can* cause a disaster.

Sure, weak typing is much poorer than strict typing for error checking. =
Does that mean the user should be prevented from having the choice?

Are you simply opposed to the idea of weak types in general?=20

> What I would suggest is the '(type) $weak' vs 'type $strict' syntax
> that was already mentioned.
>=20
> I've said this before, during the previous RFCs discussions - all of
> these proposals will fail, because they all suggest using the 'type
> $whatever' syntax and that automatically upsets the "other camp",
> whichever it is, but especially if the "other camp" is supporters of
> strict typing. That's the moment when they become opposition, while
> they could've otherwise not care because it's simply not their
> "battle". If both are proposed to co-exist in a clean way (instead of
> via a switch), I believe that we'll get substantially more positive
> opinions from both sides.

Both co-existing doesn=E2=80=99t solve anything, if anything it makes it =
worse.

People who like weak typing don=E2=80=99t want to have to use APIs with =
strict type hints. If you=E2=80=99re like Zeev and believe it is =
fundamentally at odds with PHP, you=E2=80=99ll especially dislike it.

People who like strict typing don=E2=80=99t want to have to use APIs =
with weak type hints.

>=20
> And to hell with the "consistency" argument. Since when did PHP become
> *that* concerned about purity and high consistency levels?

I don=E2=80=99t care if PHP is concerned about it. I am concerned about =
the mess caused by having two or three different argument type checking =
modes being used within the same function.

Marco and S.A.N.:

>=20
> On 15 Jan 2015, at 19:45, Marcio Almada <marcio.web2@gmail.com> wrote:
>=20
> Hi,
>=20
> I would like to call everyone's attention, specially people
> contributing directly to this RFC series, to what S.A.N just said:
>=20
> > Many developers PHP offers dual syntax:
> >
> > 1. Strict
> > function bar(int $num){}
> >=20
> > 2. Lax
> > function bar((int) $num){}
> >
> > Maybe it makes sense to put this option on the ballot if it passes a =
vote,
> > it will be possible to put an end to the discus?
>=20
>=20
> This idea has been **so recurrent** and yet systematically ignored by =
RFC owners. Why? I think that we need to baby step and try to approve =
coercive type declarations first and decide upon a possible stricter =
type check later:
>=20
> How a bout a reboot of what ircmaxell@php.net already started in =
https://wiki.php.net/rfc/parameter_type_casting_hints for v0.3?
>=20
> PS: Please, let's not fall into the mindset of "if v0.2 is not a good =
idea then v0.1 instantly becomes more acceptable", we still have time to =
try some alternatives.

See what I said above to Andreey.

This RFC doesn=E2=80=99t ignore having two syntaxes. It sets out to =
avoid the nightmare that two syntaxes would cause.

Thanks.

--
Andrea Faulds
http://ajf.me/