On 21/04/16 20:11, Fleshgrinder wrote: > 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.
Add string handling to that. It's all very well knowing that the variable is a string rather than an integer, but the length ten becomes an important element of the validation. > 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. One problem I'm struggling with is just when enabling 'strict types' is the best tool as with the other type elements that have crept in. Is it easier to handle the validation in a generic way and check for the fine detail which the crude type checks simply miss. > 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. While some of my client systems are now 64 bit, many of the windows based machines HAVE to be configured as 32 bit simply to maintain access to the hardware. So 64 bit SEQUENCE numbers need to be transparent on 32 bit builds where an 'int' may simply truncate the number? > 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. I don't enable mysqlnd if I can help it. I don't use mysql, so my data handling is via ADOdb so my base target is http://hg.lsces.org.uk/hg/Bitweaver%20Mirror/externals/adodb/file/6ca8e39bf7f5/drivers/adodb-firebird.inc.php and if this type checking sugar has any place in there? > 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. Bitweaver started off as a port of tikiwiki. It's user base has waned a little, but while tikiwiki lost access to use firebird and some other databases, we maintained that in bitweaver, and while you can use PDO if you insist, ADOdb maintains a level of cross database working that is STILL far superior to the abstractions that are currently playing catchup. > 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. PSR is NOT the road map for PHP and has many 'demands' that conflict with a sensible roadmap. > In the end it is about better APIs for me as I explained in many other > messages and I stay true to that. :) -- 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
