On 4/20/2016 11:03 PM, Stanislav Malyshev wrote: > No of course not. The specific instance of error you had *this time* may > be solved. The problem won't be. You still have to deal with: > - How this object is initialized? How you ensure it *is* initialized and > that initialization is correct (0 is perfectly valid int)? > - How this object is unserialized and what if unserialized data has > non-integer or 0 or __wakeup has a bug? > - What if some code just writes 0 into $olderThan - you declared it as > public so anybody could mess with it? > - What if some code mixes signed and unsigned and you get negative > number instead of positive? > - What if this code runs on 32-bit but receives 64-bit value and > truncates it? > > And so on, and so forth, I probably missed more possibilities than I > mentioned. Declaring a type does not magically free one from correct > design and testing, and typed programs have bugs as much as non-typed > ones (maybe slightly different ones). Actually, one of the harms relying > on it would be the same problem safe_mode had - it's full of holes, it's > not safe and it creates wrong expectations. If you just write "int" and > expect your problems to magically go away - you're in for big and bad > surprises. >
While I agree with Stanislav and the others that a stricter type system would not have prevented the bug. However, a stricter type system helps to limit the amount of tests one has to perform and that is often a good thing. That does not mean that dynamic type systems are shit. Actually the opposite is the case, it is the same situation with paradigms. What I love about PHP is that we have a lot under one hood: multi-paradigm as well as loose and strict types. This allows one to choose the best tool for the current job. Relying on your language for a bit of safety as asked of it cannot be compared to `safe_mode` where magic happens in the background. When one declares and `int` than it should be an `int`. Of course that also means that one should know what an `int` is and how to validate it according to the current business rules. That being said, isn't Lester's goal to validate scalar strings all the time anyways? I mean, at least `mysqlnd` transforms all data from the DB automatically to the proper scalar types for optimal performance in your program. But if one keeps scalar strings everywhere and leaves proper type coercion to PHP, I mean, why not. It is definitely doable and strict types are definitely not necessary if done properly. The big difference I see is that Lester is working on his code for himself (or for a customer) and does not have to design APIs for hundreds of other developers. PHP is used in the way it was initially designed, as a glue language. I repeat myself but I cannot see the need for strict types here. If you are developing APIs that are going to be (ab)used by hundreds of other developers in ways you would never have foreseen things change. One wants to ensure that the API is as self-explanatory as possible and as easy to use as possible. This includes (to get back to one of your examples) that objects that should not be serialized are not serializable (`private function __sleep()`) and not deserializable (`private function __wakeup()`) nor cloenable if necessary. This includes self-explanatory required types, sane default values, and appropriate visibility of things. PhpDoc is the classical tool for us here and Stanislav wrote in another thread that this is the tool of choice. I completely disagree with this because PhpDoc might be nice and already features more complicated types (e.g. unions), however, it is also lacking many features as the development of the PSR-5 shows. Another problem is that documentation is not kept in sync and it is extremely hard to teach people how important proper documentation is. Believe me, I know. You might say now that those programmers are bad, well, yes, maybe. But that is what you get when you are working in huge teams; ask Google. In the end it is about better APIs for me as I explained in many other messages and I stay true to that. :) -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
