I might answer you by given a scenario that happened this week here at work.
Because our non-broken language relies on a loose type system, a developer of my company wrote a property that accepts null, int, string, object, whatever as a property. This property was declared in a class that is used in a console command that runs weekly. This property was supposed to hold an integer (value in hours) that would calculate a difference in time and cancel prospected purchases older than this variable hours. All unit tests passed, because they inspect the parts not the whole. By mistake, the developer forgot to provide a value. Nothing was reported in PHP because the language is not broken, and because there's no final and no typed property, no error was reported and code proceed execution. That value that was not initialized and got assigned as null. This value was then converted to 0, and all purchases older than "now - 0 hours" got cancelled. The outcome is easy to grasp. Because it did not crash by a TypeError (which would also require the file to be declared as strict), and we lost 100k in sales. But PHP does not need more strictness... Regards, On Wed, Apr 20, 2016 at 3:22 PM, Lester Caine <les...@lsces.co.uk> wrote: > With all of the debate on the 'type system', can I just ask a probably > silly question ;) > > I'm currently working on porting an application that has been running on > windows as C++ code for 20 years. The main reason for changing is that > While it worked fine when sites upgraded to XP, the move to W7 and later > really needs all the code recompiled, something that will need a big > cheque book to buy a current compiler set. So for many reasons a switch > to web based using already existing tools makes perfect sense. > > The database is still running Firebird since the switch from interbase > in the late 90's so all of the existing data can be maintained, and I > already have a working base on which to build a new set of page > templates. ( Only hole is the need for a decent javascript scheduler > function to replace the desktop one :( ) > > This is all running on SQL based schema's which have not changed in > years, and ADOdb still quite happily produces arrays of results for > which there is little point creating new 'objects', just simply handling > the basic variable entries in the arrays just as I have for years. The > various tools handle data validation, and 'null' is an essential > component of that validation process. This does not need any of the > overload of creating 'getters and setters' and I see little point trying > to add any 'type' casting into the process since the validation layer > simply works with the bog standard variables without and need for > 'special cases'. > > So what benefit does all of the additional 'facilities' now being piled > on give that would actually improve that process. I am now seeing a > speed improvement on the PHP7 ports, but I'm not seeing any point to > make any changes to code OTHER than making the PHP5.2 code clean on PHP7 > ... As Zeev has already said "PHP is not broken" ... Do I really need to > change the way I work which is running fine for my clients? > > -- > 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 > > -- Guilherme Blanco Lead Architect at E-Block
