Re: [RFC Proposal] var keyword deprecation/removal

"Andrew Brown" wrote in message news:CAH=AbGJAnYK1Vra+7mU=Ldcb+9Tp6+qbT9yaVzX60GJ=YJsTnA@mail.gmail.com...

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.

We developers are constantly being told that we should *ALWAYS* upgrade to the latest release as soon as possible otherwise our code will be subject to security flaws. We would *LOVE* to upgrade without the fear of having our code stop working simply because some clever cloggs has broken the language simply removing a feature that was not doing any harm.

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.

PHP 4 constructors have always worked in PHP 5 simply because they were never deprecated. My PHP 4 code is still running with version 5.6.19

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.

Apart from installing the new executables there should be *NO* additional effort required to upgrade. Valid code which ran in the previous version should also run in the new version.

and I would imagine changing your vars to public is a *relatively* simple update, compared to some other possible BC breaks.

Whether it is simple or not is irrelevant - it is not necessary in the first place.

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.

What we as userland developers do with our own code only affects us. What you as core developers do with the language affects every one of the millions of userland developers all over the world. It does not matter that certain features have alias names - all a confused developer has to do is RTFM and all confusion disappears. Unless an exiting feature or function causes a GENUINE problem then it should be left alone. No effort should be wasted in taking it out and pissing off a huge number of userland developers. You as core developers may not like it, but you are there to serve the needs of the userland community, NOT to enforce your personal preferences on that community.

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.

How many millions of developers did that change affect? How many applications did that affect?

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.

Define "consistency". Consistency with what? -- Tony Marston