Re: STH and the 3 RFCs

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