Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85034
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.182 as permitted sender)
References: <CAFp73XvmrZ3VTEHAoUAMgFbK1Sx5D4CdQpT9e9+=HQUBFGNuKw@mail.gmail.com> <55033D61.8050405@lsces.co.uk>
In-Reply-To: <55033D61.8050405@lsces.co.uk>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii
Message-ID: <CFD2AB9E-E72F-4D2A-94E0-92CA13D5F155@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Date: Mon, 16 Mar 2015 22:54:37 +1100
To: Lester Caine <lester@lsces.co.uk>
Subject: Re: [PHP-DEV] STH and the 3 RFCs
From: davidkmuir@gmail.com (David Muir)


>> On 14 Mar 2015, at 6:41 am, Lester Caine <lester@lsces.co.uk> wrote:
>>=20
>> On 13/03/15 18:53, guilhermeblanco@gmail.com wrote:
>> By considering PHP's nature, having a dual mode is a WTF. I can see mysel=
f
>> asking multiple times a day "is this file strict or not?" to trace
>> potential bugs or type juggling. I do want strict, but I don't think it's=

>> the right time for PHP to make this move. Userland would have strictness,=

>> but all internal functions are a weird WTF type juggling mode. I original=
ly
>> switched my vote many times in the v3 of the RFC, mainly because PHP
>> developers are the ones that would suffer by these configurability on a
>> daily basis. I ended up with a YES vote because when considering STH or
>> nothing at all, I prefer to have some.
>=20
> The bigger WTF is perhaps that moving forward one has no idea just what
> a third party library is using internally. A case has been made that
> this does not matter since calling that library from a non-strict site
> will simply work as now, but in that case the library is not designed to
> handle non-strict input. It assumes that the strict check happens, where
> a well designed 'weak' library will be handling the edge cases properly.
> It not simply a matter of "is this file strict or not?" but rather "what
> happens when I pass the wrong data?".

If I've understood the RFC's correctly, your point is moot. With any scalar t=
ype hints, a library will not be able to tell how it is being called. All it=
 knows is that it has received an int, string, float, or boolean where it ha=
s asked for one. A library written in weak or strict mode will have no beari=
ng on its public API. This is the case with all of the STH RFCs.=20

So no, a weak mode library is not better off. It is actually worse off becau=
se it has more edge cases where things could go wrong (internally), while a s=
trict library will not function at all until the edge cases are actually tak=
en care of.

As far as being a user of the library itself, the strictness or weakness of t=
he library code is irrelevant. You can use a weak library in strict mode, an=
d the library would never know or care.

if you decide to make all your own code strict, you're not changing the beha=
vior of the library. If you make all your own code weak, you're not changing=
 the behavior of the library. Even if you strips out all the declare strict s=
tatements, it will not change the behavior of the library (except in the cas=
e where the code was broken and wasn't even working previously!).

I think the best way to explain the dual mode RFC is to think of it like thi=
s:
Imagine PHP threw a COERCIBLE_TYPE_MISMATCH notice whenever you pass the wro=
ng type to a function. In weak mode, the type gets coerced, the notice is ig=
nored, and we truck along as if nothing happened. Strict mode is basically w=
here you've set up a custom, per-file error handler where COERCIBLE_TYPE_MIS=
MATCH notices are turned into fatal errors. It is your code that decides whi=
ch error handler to use.

Cheers,
David