TRIMMING TO COMPENSATE FOR TOP POSTING !!!! On 08/03/16 17:19, Andrew Brown wrote: > the main argument against removing var that I continue to hear is that 'my > old code won't work anymore because of this unnecessary BC break'. but the > thing is, your code *will* continue to work. unless *you choose* to upgrade > your PHP version. if you stay on the current major version, it will > continue to work just fine. just like your PHP4 constructors will continue > to work on version 4, etc, etc.
This is exactly why PHP5.2 and PHP5.3 are still so common. MAKING the changes to allow code to work on later versions simply takes a resource that is not available, and while PHP does not support these older versions, ISP and others do. It's the easy option, and there are many examples where ISP's forced an upgrade on their PHP only to have so many broken sites they had to back peddle. > Of course, someone will say, 'but I want the new features and speed > improvements', which is valid. But I feel it is unfair to the language > developers, with all of the work *they* put in, to expect that we as users > of the language don't have to put in any effort to upgrade to a new major > version. and I would imagine changing your `vars` to `public` is a > *relatively* simple update, compared to some other possible BC breaks. The speed improvements implemented in PHP7 were unrelated to the changes made to the language. They were specifically designed with that in mind, but they did require that every extension was reworked to be compatible. Another area that the work load grows. But the fact that security fixes are only applied to recent versions makes that a reason why one has to upgrade the platform ... or simply spend time back porting those security fixes. But in my book, there is no reason new improvements can't be kept to new extensions, so one can leave them off if one is not using them. I don't use MySQL -so I don't need any MySQL extensions. > If we, as application developers, had duplicate code, or code that was > often the source of confusion, we would probably do our best to remove the > duplication and confusion, even if (technically) the code wasn't > hurting/breaking anything. this makes our future work easier on ourselves > or future developers. I think it is unfair of us to expect any different > from the language maintainers. Having to add 'compatibility' fixes has been one way of allowing older and newer code to co-exist, and often the duplicate code is a result of the upgrade process. But you next point is one of my biggest grumble ... > here's an example that actually occurred in application code of mine. by an > oversight I had 2 helper functions named `validation_state()` and > `validationState()`. the intention of both was the same thing, and to start > they both did exactly the same thing. Some places in my app used > `validation_state` and some other places used `validationState()`. > technically the code worked, so I thought nothing of it. then one day I > made a minor change to `validation_state()` but forgot that > `validationState()` existed, and didn't make the changes there as well. > This caused inconsistencies in my application, and the problem was not > immediately apparent. after that occurred I decided to spend 30 minutes, > and completely remove the `validationState()` function, and replace all > occurrences of it with `validation_state()`. Yes, I had to put in a little > work, but it was worth it for cleaner, more consistent code. The changes between Smarty 2 and Smarty 3 incorporated similar changes and the 'validation_state' style of naming was replaced by the 'more modern' validationState style. So you seem to be going against 'current practice'. My problem having decided that PHP7 should avoid using the 'BC' duplicate functions and go with 'clean' Smarty3 naming, there are bugs on a number of sites now with the old style and I've not yet managed to isolate the faulty code ... so I've had to switch back on the 'BC' hacks just to keep them working :( It all takes time that perhaps need not have been wasted since ALL that changed was some ones preference of coding style :( > consistency is key to make the language easy to understand for the language > maintainers, and for the language users, and especially for new users of > the language. Since the bulk of material a new user will use is style following 10 year old examples and MySQL is still the norm, new users will not see the changes anyway ... We do need GOOD modern practice examples on how things should be done today. That is what is missing. ( DON'T NEED TO DUPLICATE SIG LINES but then your email client should be modern enough to recognise the '--' flag? ) -- 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
