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.
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. 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. 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. 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. thanks, On Tue, Mar 8, 2016 at 7:05 AM, Lester Caine <les...@lsces.co.uk> wrote: > On 08/03/16 10:12, Tony Marston wrote: > > > > The only thing I am learning here is that there are too many cooks > > spoiling the broth. There are too many people who want to change the > > language into something it was not meant to be. There are too many > > people who have this notion of language "purity" and "perfection" and > > want to force their personal views on the whole of the PHP development > > community. They don't care about all those BC breaks which prevent the > > quick take-up of new versions. > > > > When large organisations invest in their software applications they > > expect stability and longevity. By creating BC breaks with every new > > version of the language you are destroying those expectations and > > sending a message to millions of developers "Don't bother using this > > language as what you write today won't work in 5 year's time". > > I've been providing a caller management system since the early 90's. The > JOB it does has not changed in 20+ years, although the reports have > changed over time. This was originally based on proprietary terminals > ... PC's were not something you found out on the counters then. As that > changed, these were replaced with a PHP based application and became web > based. Still doing exactly the same job. That job has not changed even > today, but some sites that have introduced 'improvements' such as > virtual desktops and thin client devices have made the job more and more > difficult. One site can't even tell me which building a user is working > from because the system does not identity the physical hardware. > Fortunately the 'older' services still work so one can at least bypass > it and retain the location information, but they have invested too much > to admit the real mistake! Problems like this get missed when 'improving > services' goes blindly down a particular path, and PHP seems to be stuck > in such a rut with new features like Reflections, Traits, magic > functions and so on when the vast majority of current applications > simply don't need to be changed at all. I'm once again going through > perfectly functional code to clear up warnings are now appearing on a > server I though HAD all been brought up to be PhP5.5 clean. And I know > I'll have to do the same exercise again later for PHP7. Don't say "Just > switch off the warnings" ... THAT is what has built up the backlog of > work from PHP5.2 ... so adding even more warnings is not helping improve > PHP ... > > -- > 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 > > -- Andrew M. Brown
