On 16/03/15 11:54, David Muir wrote: >>> On 14 Mar 2015, at 6:41 am, Lester Caine <les...@lsces.co.uk> wrote: >>> >> >>> >> On 13/03/15 18:53, guilhermebla...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
