Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85052
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <5506D89B.2060101@lsces.co.uk>
Date: Mon, 16 Mar 2015 13:20:27 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAFp73XvmrZ3VTEHAoUAMgFbK1Sx5D4CdQpT9e9+=HQUBFGNuKw@mail.gmail.com> <55033D61.8050405@lsces.co.uk> <CFD2AB9E-E72F-4D2A-94E0-92CA13D5F155@gmail.com>
In-Reply-To: <CFD2AB9E-E72F-4D2A-94E0-92CA13D5F155@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] STH and the 3 RFCs
From: lester@lsces.co.uk (Lester Caine)

On 16/03/15 11:54, David Muir wrote:
>>> On 14 Mar 2015, at 6:41 am, Lester Caine <lester@lsces.co.uk> wrote:
>>> >> 
>>> >> 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 myself
>>> >> 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 originally
>>> >> 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.
>> > 
>> > 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 type 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 has asked for one. A library written in weak or strict mode will have no bearing on its public API. This is the case with all of the STH RFCs. 
> 
> So no, a weak mode library is not better off. It is actually worse off because it has more edge cases where things could go wrong (internally), while a strict library will not function at all until the edge cases are actually taken care of.
> 
> As far as being a user of the library itself, the strictness or weakness of the library code is irrelevant. You can use a weak library in strict mode, and the library would never know or care.
> 
> if you decide to make all your own code strict, you're not changing the behavior 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 statements, it will not change the behavior of the library (except in the case 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 this:
> Imagine PHP threw a COERCIBLE_TYPE_MISMATCH notice whenever you pass the wrong type to a function. In weak mode, the type gets coerced, the notice is ignored, and we truck along as if nothing happened. Strict mode is basically where you've set up a custom, per-file error handler where COERCIBLE_TYPE_MISMATCH notices are turned into fatal errors. It is your code that decides which error handler to use.

Thank you for that David ...
It makes sense of a number of points.
I think that what I really need is a simple crib sheet of 'just' weak
typing in this RFC and if that conflicts with my own current program
flow. I simply don't subscribe to the implication that type hinting is
essential to make PHP better. I just prefer in-line error handling to
exception handlers.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk