Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85056
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.45 as permitted sender)
References: <CABBJUpfiy1BpdyZ5MJmQb3vQz9U8TkSECHCRctupV+BUG1H=fw@mail.gmail.com> <55066F07.80308@birkholz.biz> <CABBJUpd+yd_7g8VkU0SHRMt0a35idyyLS_7m6=-cGgBB1RzkQg@mail.gmail.com> <CAN=kQJe6civW3x=uT2wMB7Mb-33LvkSyHfU=FfB8cfbWsVE+_A@mail.gmail.com> <CAGa2bXaMPs2WNOvJzJz6S3Qm1z28H=msi8SdVsmPYJGz-kM8hQ@mail.gmail.com> <5506794B.8090008@birkholz.biz> <CAGa2bXbGxr4E8hi1_faNWOWSeLi6kn5kQJknCaZ4vUTNxHR+tg@mail.gmail.com> <CAEZPtU68oFYN5YoQk7+kJPDancrfj9eEbau9BCB6OgkQEV7p8Q@mail.gmail.com> <CAGa2bXYU4LVDdVdCjRUbqvFbkBzy_U3O21Hu7uarZBK_F=ir8A@mail.gmail.com> <alpine.DEB.2.11.1503161120100.4205@whisky.home.derickrethans.nl> <CAB6YZuxhAGsRrOKTSNF5nt4bwxHSx9B-NakDk9hzPTu0HWTOFA@mail.gmail.com> <CA+kxMuQCeki05C8PNQf7_XPc_vPg7_6rvCGfyp2fsRorE1=aTg@mail.gmail.com> <CAB6YZux9kyy=r3z=GSePDkJ85eND8G+hXsPvivCE7RLZN42V9A@mail.gmail.com>
In-Reply-To: <CAB6YZux9kyy=r3z=GSePDkJ85eND8G+hXsPvivCE7RLZN42V9A@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8
Message-ID: <034E5D70-C0E3-412B-A18E-ECFF3033773F@gmail.com>
Cc: Dan Ackroyd <danack@basereality.com>, Derick Rethans <derick@php.net>,
 Pierre Joye <pierre.php@gmail.com>,
 PHP internals <internals@lists.php.net>,
 Dennis Birkholz <dennis@birkholz.biz>
Date: Tue, 17 Mar 2015 01:08:09 +1100
To: =?utf-8?Q?Pavel_Kou=C5=99il?= <pajousek@gmail.com>
Subject: Re: [PHP-DEV] About declare(strict_types = 1)
From: davidkmuir@gmail.com (David Muir)



>> On 16 Mar 2015, at 11:16 pm, Pavel Kou=C5=99il <pajousek@gmail.com> wrote=
:
>>=20
>> On Mon, Mar 16, 2015 at 1:04 PM, Dan Ackroyd <danack@basereality.com> wro=
te:
>>> On 16 March 2015 at 11:49, Pavel Kou=C5=99il <pajousek@gmail.com> wrote:=

>>>=20
>>> Seriously, think about it for a while - when some setting that changes
>>> how code behaves was a good idea?
>>=20
>>=20
>> The problem is that there are two irreconcilable camps - some people
>> want weak STHs, other people want strict STHs.
>>=20
>> This RFC gives both camps what they want, at the cost of having the dual m=
ode.
>>=20
>> I personally would prefer a single mode, with strict STHs but I can
>> see that would piss off the other camp. And so to me, this RFC even
>> with the ickiness of the setting, is an an acceptable cost to giving
>> both sides what they want. Oh, and people who don't want to use scalar
>> type hints at all, can still continue to not use scalar type hints,
>> and their code will continue to keep working.
>>=20
>> Anyone who is voting no, isn't doing so because they are missing out
>> on a feature, they're doing it to block other people from getting what
>> they want in PHP, which is just a terrible way to vote.
>>=20
>> And if the strict camp are wrong and strict scalars are just not used
>> by a large proportion of the PHP community, it would be trivial to
>> remove support for the strict mode in a future version of PHP, as all
>> code that runs in strict mode, will automatically work in weak mode.
>>=20
>> cheers
>> Dan
>=20
> I can't speak for anyone who voted, but personally, if I could vote, I
> would voted "no" - not because "I don't want to block people from
> getting what they want", but because I sincerely think that having ANY
> setting that changes code's behavior is bad in the long run (and that

Do you use an error handler that converts notices into exceptions? By your s=
tatement, I'm guessing no, and that you think error handlers should not be u=
sed that way as they change the code's behavior in almost exactly the same m=
anner?

> removing the feature might not be really easy, once people realize
> that the feature is really bad, as people realized with safe_mode and
> register_globals after few years).


Removing the feature is trivial! A search / replace across the code base can=
 do it, and it could be disabled at the engine level. For working code, nobo=
dy would notice the difference because strict code works in weak mode. In ot=
her words, there are no BC issues with removing the strict portion.=20

Can people stop comparing it to register globals? Have you ever tried to fix=
 a codebase that relied on it? It is impossible to detect! You really don't h=
ave many options but to step through and manually run through every single e=
ntry point into your application and test/audit every code path, and the hop=
e you catch everything. It was a global setting, removing it was a *huge* BC=
 break, and its use was undetectable. None of which is the case with dual mo=
de. There's no global setting, there's no BC with removing it, and it's use i=
s *extremely* easy to detect!=20

Cheers,
David=