Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82589
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.48 as permitted sender)
MIME-Version: 1.0
Date: Fri, 13 Feb 2015 09:37:48 +0000
Message-ID: <CACwt+JdHCYYVMbuuAZ73N_sfOkQHJ7_EkOtPWtqJcNW7Xgjn3w@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0434c0b8583d20050ef4fd49
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
From: patrickallaert@php.net (Patrick ALLAERT)

--f46d0434c0b8583d20050ef4fd49
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le Thu Feb 05 2015 at 21:15:45, Andrea Faulds <ajf@ajf.me> a =C3=A9crit :

Good evening,
>
> At long last, I=E2=80=99m going to put the RFC to a vote. It=E2=80=99s be=
en long enough -
> I don=E2=80=99t think there needs to be, or will be, much further discuss=
ion.
>
> I=E2=80=99d like to make sure that everyone voting understands the RFC fu=
lly.
> Please read the RFC in full: the details are important. And if  anyone ha=
s
> any questions or uncertainties, please ask them before voting. I am very
> happy to answer them.
>
> I would urge everyone who wants type hints to vote for this RFC. It is no=
t
> a perfect solution, but there can be no perfect solution to this issue.
> However, I think it is better than most of the alternatives suggested thu=
s
> far - see the rationale section, and previous discussions. Crucially, thi=
s
> RFC would keep PHP a weakly-typed language, and not force either strict
> typing, nor weak typing, on anyone who does not want it. It would allow t=
he
> addition of type hints to existing codebases. It would not create a
> situation where userland functions are strict yet internal functions are
> not, because the strict mode affects both. I=E2=80=99ve tested the implem=
entation
> myself on my own code, and it worked well, providing benefits other
> proposals would not have given (see my previous post about my experiences=
).
>
> Voting starts today (2015-02-05) and ends in two weeks=E2=80=99 time (201=
5-02-19).
> In addition to the vote on the main RFC, there is also a vote on the type
> aliases issue, and a vote to reserve the type names for future RFCs=E2=80=
=99 sake
> if this RFC fails.
>
> The RFC can be found here, and it contains a voting widget:
> https://wiki.php.net/rfc/scalar_type_hints
>
> Thank you for your time.
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Voted "no" because of the reasons already mentioned by a bunch of others
here.

Weak type hint as presented earlier: +1 (and very good job Andrea about
that!).
declare(strict_types=3D1): -1, not only about the syntax, but also about th=
e
mixed mode it introduces.

I'm pretty confident that this RFC will "pass" with just above 2/3 of
majority while it could reach much more.

 I am pretty sure that if this RFC doesn't include a strict type mode _the
way it is proposed_ (or even, not at all, as part of another related RFC),
it would have some "no" converted to "yes" and would have a wider adoption,
which is for sure a better option than relying on a voting mechanism which
still is a supporting tool, we're not politicians after all :)

Andi's suggestion about an E_STRICT_TYPES sounds very reasonable and much
more in line with how PHP deals with "errors". However, I think this should
be discussed separately as this is really about the A + B think that Zeev
was talking about.

Cheers,
Patrick

--f46d0434c0b8583d20050ef4fd49--