"Andrew Brown" wrote in message
news:CAH=AbGJAnYK1Vra+7mU=Ldcb+9Tp6+qbT9yaVzX60GJ=yjs...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
