Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82250
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zeyos.com designates 109.70.220.166 as permitted sender)
Date: Mon, 09 Feb 2015 10:22:04 +0100
To: Andrea Faulds <ajf@ajf.me>,
	Zeev Suraski <zeev@zend.com>,
	Pierre Joye <pierre.php@gmail.com>
Cc: PHP internals <internals@lists.php.net>,
	Matthew Leverton <leverton@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset="UTF-8"
Message-ID: <20150209092210.7CEDE5F8A7@mx.zeyon.net>
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
From: ben.coutu@zeyos.com (Benjamin Coutu)

Hello everyone,=0A=0A(Un)fortunately I do not have voting rights, but here =
is my (freely expressed) 50 cents anyways:

I appreciate that Andrea is trying to come up with a one-size-fits-all RFC.=
 Nevertheless I believe it is flawed in regards to content as well as forma=
lly in terms of voting options.

In my view this has become a fight over feature request vs. language consis=
tency. I understand that a large part of userland is or would be in favor o=
f this RFC - they always prefer new features as long as they are backward c=
ompatible. You might as well introduce an (configuration/declare) option fo=
r static typing, and userland would probably cheer. This does not necessari=
ly make it a good thing though.

You, @internals, are the guardians of this language and should consider int=
rinsic language consistency as a paramount objective. At the end of the day=
 PHP is fundamentally a weakly typed language. Introducing an optionality i=
n how the fundamental semantics of the language work (with the declare-prop=
osal) is not well thought trough. It is by all means quite hacky - reminds =
me of register-globals, mb-function-overloading, etc. - everything bad abou=
t PHP. As we all know bad things cannot be revoked easily once introduced.

This doesn't mean strict type hinting cannot be done in a coherent way. The=
re have been good (or at least compatible) proposals, e.g. seeing "(type)" =
as a weak hint and "type" as a strict hint. This would be somewhat consiste=
nt with both, casting expressions as well as the existing strict/strong typ=
e hints for objects. But maybe having both is not the right (PHP) way after=
 all. The only thing 100% consistent with the current language semantics wo=
uld be no type hinting at all or some form of weak type hinting. Everything=
 else would be nice to have, if (and only if) done right.

Ultimately, and I am sorry to say that, I think this discussion is symptoma=
tic for the lack of professionalism among the PHP community, keeping many p=
otential contributors (like my colleagues and myself) from actually committ=
ing resources apart from mere observation. I find it very discouraging that=
 well argued opinions of lead developers of this project, such as Andi, Ras=
mus and Zeev, are dismissed so bluntly. I do not recall any instance in the=
 PostgreSQL community where Tom Lane or some other senior contributor has b=
een so harshly treated. Having the original designers of the language keenl=
y reject this proposal should be a concern to all of us, independently of s=
ubjective opinion or the current voting result.

The honorable (and rational) thing to do would be for the author to retract=
 this RFC and thereby postpone the decision (I am aware that the feature fr=
eeze looms!). This is so important for the future of PHP, so let's don't ru=
sh it, but try to do it right!=0A=0ACheers,=0A=0ABen=0A=0A=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D Original =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0AFrom: Matthew Lev=
erton <leverton@gmail.com>=0ATo: Zeev Suraski <zeev@zend.com>=0ADate: Mon, =
09 Feb 2015 05:20:25 +0100=0ASubject: Re: [PHP-DEV] [VOTE] Scalar Type Hint=
s=0A=0A=0A=0AOn Sun, Feb 8, 2015 at 3:22 PM, Zeev Suraski <zeev@zend.com> w=
rote:=0A> I'm well aware of it as I wrote that policy.  The goal of the pol=
icy was to=0A> prevent a situation where a temporary majority can introduce=
 features into=0A> the language that would later on be impossible to revers=
e.  It's not by any=0A> stretch a good mechanism to solve controversial vot=
es, which again, should=0A> ideally be avoided as much as possible.  It's j=
ust that there isn't a better=0A> mechanism.=0A>=0AI know I'm unfairly para=
phrasing you, but it sounds like you are=0Asaying that for things that you =
don't have strong feelings about, then=0Ayou're fine if the others vote amo=
ngst themselves. But for things that=0Amatter to you, you want to reserve t=
he right to prevent change. Is=0Athere a way to fairly describe what you co=
nsider too controversial to=0Avote on?=0A=0AThe problem I see with votes fo=
r this type of feature is that you=0Aprobably have a breakdown of something=
 like:=0A=0A- 10% of people don't want scalar type hints=0A- 20% of people =
want both, but 50% of them would vote for either weak or strong=0A- 35% of =
people want strict, but 80% of them are fine with weak=0A- 35% of people wa=
nt weak, but 80% of them are fine with strong=0A=0ASo if a strict-only vote=
 happens first, you get 73% to say yes. If=0Aweak-only vote happens first, =
you get 73% to say yes.=0A=0A(I'm obviously just making up these numbers wi=
th no scientific basis,=0Abut I think the principle is valid.)=0A=0AThe onl=
y way to be fair IMO is to hold a vote where you rank those=0Afour options =
(weak, strong, both, neither) and hold an instant run-off=0Avote where the =
first majority wins. And if 'neither' wins, then agree=0Athat the topic can=
not be revisited until next major version, so that=0Aeverybody can rest for=
 5 years. ;)=0A=0A--=0AMatthew Leverton