wrote in message news:56cdeb49.5040...@fleshgrinder.com...
On 2/22/2016 9:12 PM, Stanislav Malyshev wrote:
Hi!
Hey there. :)
On 2/22/2016 9:12 PM, Stanislav Malyshev wrote:
Old cellphones were shipped with a user manual that contained precise
instructions on how to deal with the installed OS.
You don't really need a whole manual to know two things are the same.
You only need one line from that manual. It's a minimal effort, well
within expected of what may be required of a person learning new
language - I think reading a couple of lines is not excessive.
New smartphones do not contain a user manual because the OS is so
intuitive that nobody has a need for them.
Or so the marketing team would love us to believe ;)
If you think a programming language somehow can be so "intuitive" that
you never need to actually know anything to use it - you're in for a
somewhat unpleasant surprise, unfortunately. We can make learning it
easi-er - and having aliases is part of it - but we can never make it so
easy as never having to actually touch the manual or any other learning
media.
My example seems to be bad or to abstract. I am not thinking that a
programming language can become that intuitive; the contrary.
Programming languages are already so complicated that it is harmful to
start littering them with thousands of ways to achieve one thing. It
also makes users uncertain when the manual entry says that something is
an alias. They fear that it might be removed.
That fear is unjustified. They need to learn the difference between
"duplicated" and "deprecated". Unless a function is marked as "deprecated"
it cannot be removed.
They create project rules that forbid the usage of aliases ...
We cannot stop stupid people from creating stupid rules.
Science shows that it is harmful, let's clean it up!
Your "proof" is not scientific, it is just personal opinion. There is no
evidence that use of the "var" keyword is harmful in any way.
discussion because you simply say no and do not even allow a
That is not correct. I say no with substantiation - namely, that
removing aliases would cause code breakage and would not add anything to
actual functionality. Your argument seems to be generic "redundancy is
bad" argument, and treating somebody asking questions on stackoverflow
as evidence that we have a problem. Both are wrong - redudancy can be
both good and bad, and in our case I think it is good because it lets
people continue to rely on their previous experience both in PHP and
other languages. Also, somebody asking questions is not a reason to
change the language - there always will be people asking questions, and
that's fine as long as we have good easily accessible answers, which we
do.
In Germany we say "jain" (yes and no). You are right that you brought up
that argument and I acknowledged it but put it like you did not bring up
one in my last message. I am sorry for that. You are not right that
Stackoverflow is my only argument. I provided scientific proof that
those aliases harm the design of a language and a more general proof in
regards to usability and duplication.
Again, your "proof" is NOT scientific, it is merely a personal opinion.
People often rely on side effects but that does not mean that this is a
good practice. We are talking here about a feature that was added in PHP
4 in order to support OO coding. The feature is not used anymore by a
major part of the community and it is considered best practice to use
Where is your proof? You say "not used by a major part of the community"
which means that it is still being used by a minor part, but exactly how
"minor"? I don't see why I should be forced to make a totally unnecessary
change to vast numbers of my scripts just to fall in line with your personal
opinions.
the proper access modifiers (namely public in this case). We are talking
about a future version of PHP (probably 8) and not about removing it
from PHP 4, 5, nor 7.
There is no reason to remove it from ANY version of PHP. It does no harm, it
would take effort to take it out and amend the documentation, but for what
benefit?
There is only one constant in life and that is change. Insisting on not
changing means to stop; especially in a context of software development
and engineering (which actually implies constant change in its own name).
Change for change's sake is never a good idea. I have been developing in
several languages for 40 years, and I can tell you point blank that while
programmers expect new features to be added they do NOT expect old features
to disappear. Once a piece of code has been written and has proved to work
as designed it is expected to work with all future versions. The only
exception to this is to plug holes in security. This is called "forwards
compatibility", and was a major selling point of all my previous languages.
If developers fear that they will have to rewrite huge swathes of code each
time a new version is released they will quickly give up and move to a
"professional" language which offers long term stability.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
