Hello everyone,
I'd like to propose an RFC to deprecate and eventually remove the "var"
keyword.
My understanding is that this keyword was kept in PHP 5 for
backwards-compatibility with PHP 4. However, it's been 9 years since PHP 4
was discontinued, so I'd like to bring this topic up for review.
Usage of "var" doesn't seem to be as widespread recently. I've done a quick
search of several major projects and libraries and found that only a couple
are using it. I personally haven't seen it used in any PHP 5.3+ project
I've worked on in recent memory.
Because "var" simply acts as an alias for "public", removing it should not
cause any loss of functionality. Yes, it's a BC break, but developers can
easily replace it with "public" to maintain the same functionality.
PHP 7 deprecated PHP 4 style constructors in favor of the PHP 5
__construct() method. I'd like to propose doing the same for the "var"
keyword - deprecate it in PHP 7.1 and remove it in a future version (7.2 or
8.0?)
I'd appreciate any thoughts or feedback you may have, especially if you
have any objections to me creating an RFC for this proposal.
Best regards,
Colin O'Dell
I'd like to propose an RFC to deprecate and eventually remove the "var"
keyword.
+1
On Thu, Feb 18, 2016 at 11:30 AM, Sebastian Bergmann sebastian@php.net
wrote:
I'd like to propose an RFC to deprecate and eventually remove the "var"
keyword.+1
--
What are your reasons for this proposal?
I can think of multiple reasons why this might not be a good idea, but the
only reason that pops to mind for getting rid of it is to make PHP work
like a different style of language.
Walter
--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
What are your reasons for this proposal?
I can think of multiple reasons why this might not be a good idea, but the
only reason that pops to mind for getting rid of it is to make PHP work
like a different style of language.
I'm proposing this change because it will remove duplicate functionality
from the language.
In PHP 4, "var" was the only way to declare a class member variable. PHP 5
introduced three new keywords for this purpose: public, protected, and
private. "public" is functionally identical to "var". According to the
docs:
Class properties must be defined as public, private, or protected. If
declared using var, the property will be defined as public.
This is great for backwards compatibility from PHP 4, but it ultimately
results in having two different keywords which do exactly the same thing.
Does PHP 7 really need two keywords for declaring public class members?
We're already removing PHP 4 style constructors in favor of the PHP 5 style
ones, so why not also remove the PHP 4 "var" keyword in favor of the PHP 5
style keywords which explicitly state the visibility?
For the small percentage of projects which still use "var", upgrading their
code would be dead simple: just replace "var" with "public" everywhere you
see it. I'm sure somebody can easily whip up a tool to automate that
process.
Because current usage of "var" seems low and the upgrade path is so simple,
I don't think its a bad idea.
Colin
On Thu, Feb 18, 2016 at 11:30 AM, Sebastian Bergmann sebastian@php.net
wrote:I'd like to propose an RFC to deprecate and eventually remove the "var"
keyword.+1
--
What are your reasons for this proposal?
I can think of multiple reasons why this might not be a good idea, but the
only reason that pops to mind for getting rid of it is to make PHP work
like a different style of language.Walter
--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D.
Brandeis
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
What are your reasons for this proposal?
I can think of multiple reasons why this might not be a good
idea, but the only reason that pops to mind for getting rid of it
is to make PHP work like a different style of language.I'm proposing this change because it will remove duplicate
functionality from the language.In PHP 4, "var" was the only way to declare a class member
variable. PHP 5 introduced three new keywords for this purpose:
public, protected, and private. "public" is functionally identical
to "var". According to the docs:Class properties must be defined as public, private, or
protected. If declared using var, the property will be defined as
public.This is great for backwards compatibility from PHP 4, but it
ultimately results in having two different keywords which do
exactly the same thing. Does PHP 7 really need two keywords for
declaring public class members?We're already removing PHP 4 style constructors in favor of the PHP
5 style ones, so why not also remove the PHP 4 "var" keyword in
favor of the PHP 5 style keywords which explicitly state the
visibility?For the small percentage of projects which still use "var",
upgrading their code would be dead simple: just replace "var" with
"public" everywhere you see it. I'm sure somebody can easily whip
up a tool to automate that process.Because current usage of "var" seems low and the upgrade path is so
simple, I don't think its a bad idea.Colin
+1 for Colin’s proposal. Duplicate functionality results in confusion
and this should be avoided and cleaned-up. There are already way too
many aliased functions just to ease the learning curve for people that
come from other languages (whatever that should bring to PHP).
Richard "Fleshgrinder" Fussenegger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJWxjQwAAoJEOKkKcqFPVVrtM4P/0KQbfYSTvRAuAUiVeQZwsUO
0W5yXlBDRkQfvrxh/xdirMIw0fX25tipsB++93pJ81ay00K2o623KmMKzM4U1rzu
Pfk+HjnGN8iAQSGI0lvHCbgQLnAScOxzllB7NdchhyCP+LwTappDlT3Il/2THTg0
8ilMjBKOdG0tvwicYk4WYc8I9Z1Ryw37JUTp15sk0rE3M6OKRD7KUCVYZ1EfDTTW
0XGwfoOYT9yPEncw/p5jN0SM612kd25/4WfURsjjVhrjHk3l4UxRIh8SKacI/lWe
Zs/WAJa/Nh8gJredgiOa7KO8VnNaeNTnJlXtnhSibdLMJ7lZPUz/4Wnum3/AHAte
2bqT+/5i6AKAi+izFl5IISBL7jh4cI9F1OFT3Z0IdKy1WXJtA37s4mHRmZLMcVvw
HIJTDiBmMqE8PZVnc/Rf5A3QsQoC7h02Rnol7a5PU9990oDKW4lqxfXJRVLZT4Zf
GlImZzdZ1dkzTJlTXLGSEthPrjR3IRsR0JCls5baYLg09OeJAOvOngKeJXZsIz7d
BgoV32wlXtaWWp0hM6RWoztXymLppN8yRWMDwNhqQO7mHAI498KJyoIa46DrUVix
sp0fBOnF+1chDn9uwEkqCZrUMhb+UGQAuyJikDyQALUNmNyi4xTjdv+pjDr3X0Qf
3iz95r9fJF3XqYUsP44r
=r05h
-----END PGP SIGNATURE
""Colin O'Dell"" wrote in message
news:CAJaRsPtqPKz9XSp6jF3gpm7hn39KDqpXCX4r5yN8HsohWo1gDg@mail.gmail.com...
What are your reasons for this proposal?
I can think of multiple reasons why this might not be a good idea, but
the
only reason that pops to mind for getting rid of it is to make PHP work
like a different style of language.I'm proposing this change because it will remove duplicate functionality
from the language.
This reason is not good enough. Leaving the "var" keyword in does not do any
any harm, so what be benefit is gained by expending the effort of removing
it?
To be consistent you ought then to remove ALL other instances where there is
more than one way of achieving the same thing, but how many of those are
there? If the various duplications are still being used, then who decides
which one is to be deprecated? For example, the short array syntax was
introduced in version 5.4, so according your logic the original (and well
used) long array syntax is now a duplicate and should be deprecated. How
much effort would this require? What benefit would be achieved?
Class properties must be defined as public, private, or protected. If
declared using var, the property will be defined as public.This is great for backwards compatibility from PHP 4, but it ultimately
results in having two different keywords which do exactly the same thing.
Does PHP 7 really need two keywords for declaring public class members?
The PHP language is littered with more than one way of doing the same thing,
so do you propose the removal of ALL duplications?
We're already removing PHP 4 style constructors in favor of the PHP 5 style
ones, so why not also remove the PHP 4 "var" keyword in favor of the PHP 5
style keywords which explicitly state the visibility?For the small percentage of projects which still use "var", upgrading their
code would be dead simple: just replace "var" with "public" everywhere you
see it. I'm sure somebody can easily whip up a tool to automate that
process.
Why should long standing projects have to change their code just because you
personally don't use and don't like the "var" keyword?
Instead of tinkering with the language to achieve nothing but perceived
"purity" why don't you stick to proposing genuine improvements?
--
Tony Marston
"Walter Parker" wrote in message
news:CAMPTd_AHyV2d0_Saq=kPvhDZkKCMGkxAV8TNT4Hk9SdNGKCiiA@mail.gmail.com...
On Thu, Feb 18, 2016 at 11:30 AM, Sebastian Bergmann sebastian@php.net
wrote:I'd like to propose an RFC to deprecate and eventually remove the "var"
keyword.+1
--
What are your reasons for this proposal?
I can think of multiple reasons why this might not be a good idea, but the
only reason that pops to mind for getting rid of it is to make PHP work
like a different style of language.Walter
Your reason "make PHP work like a different style of language" is
meaningless. The removal of the "var" keyword does not change any
functionality.
--
Tony Marston
On Fri, Feb 19, 2016 at 1:10 AM, Tony Marston TonyMarston@hotmail.com
wrote:
"Walter Parker" wrote in message
news:CAMPTd_AHyV2d0_Saq=kPvhDZkKCMGkxAV8TNT4Hk9SdNGKCiiA@mail.gmail.com...On Thu, Feb 18, 2016 at 11:30 AM, Sebastian Bergmann sebastian@php.net
wrote:I'd like to propose an RFC to deprecate and eventually remove the "var"
keyword.
+1
--
What are your reasons for this proposal?
I can think of multiple reasons why this might not be a good idea, but the
only reason that pops to mind for getting rid of it is to make PHP work
like a different style of language.Walter
Your reason "make PHP work like a different style of language" is
meaningless. The removal of the "var" keyword does not change any
functionality.--
Tony Marston--
I've been doing too much C# lately, mixing up the definitions of var (C#
now uses var very frequently in coding).
--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
I'd like to propose an RFC to deprecate and eventually remove the "var"
keyword.
I'm tepidly +1 this. It's not hurting anything, but var's time has
past. Let's deprecate it, and in four year's time as we're starting
to talk PHP8, we can ask ourselves whether removal makes sense.
-Sara
Hi Colin,
Colin O'Dell wrote:
I'd like to propose an RFC to deprecate and eventually remove the "var"
keyword.
I don't have a strong opinion on that, I guess I'm in favour. It seems
like a fairly harmless deprecation.
Though if we do get rid of the var syntax, I'd like it if we kept the
reserved word, because it still might be useful in future for typed
variables or different variable scoping.
Thanks!
--
Andrea Faulds
https://ajf.me/
Hi all,
Colin O'Dell wrote:
I'd like to propose an RFC to deprecate and eventually remove the "var"
keyword.I don't have a strong opinion on that, I guess I'm in favour. It seems like
a fairly harmless deprecation.Though if we do get rid of the var syntax, I'd like it if we kept the
reserved word, because it still might be useful in future for typed
variables or different variable scoping.
Same opinion.
Keeping various syntax makes language more complex.
The same may apply to
https://bugs.php.net/bug.php?id=71614
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Though if we do get rid of the var syntax, I'd like it if we kept the
reserved word, because it still might be useful in future for typed
variables or different variable scoping.
Good idea Andrea! Thanks for that suggestion.
I do have a general question about these types of changes: if the
deprecation were to land in 7.1, when would the actual removal take place -
7.2 or 8.0? Or would that be a voting option?
I really appreciate all the feedback so far - keep it coming!
Colin
Hi Colin,
Colin O'Dell wrote:
I'd like to propose an RFC to deprecate and eventually remove the "var"
keyword.I don't have a strong opinion on that, I guess I'm in favour. It seems like a fairly harmless deprecation.
Though if we do get rid of the var syntax, I'd like it if we kept the reserved word, because it still might be useful in future for typed variables or different variable scoping.
That’s an interesting idea, -1 on the original proposal, though.
Regards,
Mike
Hi!
I'd like to propose an RFC to deprecate and eventually remove the "var"
keyword.
Don't see much point - it is the same as public and doesn't hurt anyone.
Removing it does not improve any code in any way, just makes it harder
to upgrade.
--
Stas Malyshev
smalyshev@gmail.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi!
I'd like to propose an RFC to deprecate and eventually remove the
"var" keyword.Don't see much point - it is the same as public and doesn't hurt
anyone. Removing it does not improve any code in any way, just
makes it harder to upgrade.
Although it is true that an upgrade from PHP 7 to 8 will involve more
work, it is not true that it does not hurt anyone. This is a well
known problem in design:
https://www.nngroup.com/articles/reduce-redundancydecrease-duplicated-de
sign-decisions/
This is about UI but the same principles apply to aliased
functionality in a programming language:
-
- "What is the difference between implode and join?"
- http://stackoverflow.com/questions/17914008
- http://www.php-questions.com/phpfaq/answer124
http://rajeshstutorials.blogspot.de/2012/01/difference-between-join-and-
implode-in.html
-
...
-
- "What is the difference between die and exit?"
- http://stackoverflow.com/questions/1795025
- http://stackoverflow.com/questions/12702875
- https://phillipnb.wordpress.com/2012/03/21/die-and-exit/
https://www.quora.com/Is-there-any-difference-between-die-and-exit-in-PH
P
-
...
-
- "What is the difference between is_writable and is_writable?"
-
- "What is the difference between ...?"
It confuses users and wastes their time.
Richard "Fleshgrinder" Fussenegger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJWxjp9AAoJEOKkKcqFPVVr93cP/1lE2Cxu3TRNsDybFB+3YnmN
nP6mZlApj8cPT6Q8/P6YnwKb2NZ2X9G/IuYCXzhLUTULkmiZxhxhUzPzfT3a99F9
DIHg8u+ZpOwn3baZdUJsxWouYxLtUS6mJb9BBnkvbhCklNWlX8q7A/JN/gxmm2vi
PXcLh/gEUE0D+z2+aIO5ozv7kzbk7gf0fiX1gAnnor+ACozlBHPxgO/QMLl0V9RL
Xj5jOhUIMXO6tWowmNxsSgDGHfhHD74G6AVBN/aJvqiWSfPpHEF8ZMyXuVg/BarL
9lVcBw6Hws/n40uTh/lMxo7exkAV4X8wBc0FkXPNVvYhuwivNBwsF1eO43MWT+5b
pKPAIcjyrbEOeb0CFegHRLr2Vw8g0t/VWz70LV445JgrDS9R/VicjUApRKER+blK
A6QF/K4cPtq12npNA+vFOk0o93L1tzaRakn33jk+m9wypQMqEJD/sZvbE4YVnlkB
B1c9lJJGLp/KR27iRz26+dUn+PRvL2zPT1mFk6HXoYpSHDJNLT5F5N+fgnp/Dq8n
mZmQ/Uhz2cc6/b+IVIDP18x8XKklZe103a0sCb0NVkB6WYL/Qc7S5Y/acMGmLxiJ
HhvSU6bkE0lSuzUYptmyQ+Uy/J+ChtTRjxOKHHSVR5ZCTrTKYyLuyoH56nREUiEo
KPp+WLmzxqgGDEEt33uk
=YHLQ
-----END PGP SIGNATURE
Hi!
Although it is true that an upgrade from PHP 7 to 8 will involve more
work, it is not true that it does not hurt anyone. This is a well
known problem in design:https://www.nngroup.com/articles/reduce-redundancydecrease-duplicated-de
sign-decisions/
This is all generic advice which is nice and well if we would be
designing language anew. As it is, we are not - we already have lots of
code using var. For code not using var, removing var does not do
anything. For code using var, removing var means no upgrade. It is
unnecessary breakage for the sake of feeling that we follow the advice
somebody put on the website. That feeling is not worth very real work
that people would have to do to achieve what they already have now.
- "What is the difference between implode and join?"
Yes, PHP has aliases. Nothing wrong with that, provided you bother to
look in the manual once, and then you are enlightened forever.
It confuses users and wastes their time.
It only wastes their time if they don't read the manual but instead chat
on Stackoverflow :) Which I have nothing against, it's just not the
reason to introduce BC breaks because somebody asked a question about it.
Stas Malyshev
smalyshev@gmail.com
Hi!
Although it is true that an upgrade from PHP 7 to 8 will involve more
work, it is not true that it does not hurt anyone. This is a well
known problem in design:https://www.nngroup.com/articles/reduce-redundancydecrease-duplicated-de
sign-decisions/
This is all generic advice which is nice and well if we would be
designing language anew. As it is, we are not - we already have lots of
code using var. For code not using var, removing var does not do
anything. For code using var, removing var means no upgrade. It is
unnecessary breakage for the sake of feeling that we follow the advice
somebody put on the website. That feeling is not worth very real work
that people would have to do to achieve what they already have now.
- "What is the difference between implode and join?"
Yes, PHP has aliases. Nothing wrong with that, provided you bother to
look in the manual once, and then you are enlightened forever.
It confuses users and wastes their time.
It only wastes their time if they don't read the manual but instead chat
on Stackoverflow :) Which I have nothing against,
Stas Malyshev
smalyshev@gmail.com
Hi,
Le 18/02/2016 20:10, Colin O'Dell a écrit :
Hello everyone,
I'd like to propose an RFC to deprecate and eventually remove the "var"
keyword.My understanding is that this keyword was kept in PHP 5 for
backwards-compatibility with PHP 4. However, it's been 9 years since PHP 4
was discontinued, so I'd like to bring this topic up for review.Usage of "var" doesn't seem to be as widespread recently. I've done a quick
search of several major projects and libraries and found that only a couple
are using it. I personally haven't seen it used in any PHP 5.3+ project
I've worked on in recent memory.Because "var" simply acts as an alias for "public", removing it should not
cause any loss of functionality. Yes, it's a BC break, but developers can
easily replace it with "public" to maintain the same functionality.PHP 7 deprecated PHP 4 style constructors in favor of the PHP 5
__construct() method. I'd like to propose doing the same for the "var"
keyword - deprecate it in PHP 7.1 and remove it in a future version (7.2 or
8.0?)I'd appreciate any thoughts or feedback you may have, especially if you
have any objections to me creating an RFC for this proposal.Best regards,
Colin O'Dell
Writing an RFC about it is fine, but, IMHO, it should target version 8.0.
As it was already said, deprecating it in 7.x would be probably more
negative than positive. But, deciding today that it will be suppressed
in 8.0, and leaving 5 years for devs to adapt their code, is something I
would probably support.
When discussing about PHP 7, we found a lot of changes that would have
been possible only if they had been announced several years in advance.
That's why I think that, even if we just released version 7, we can
start discussing such changes for 8.0.
Regards
François
Hi!
2016-02-18 15:10 GMT-04:00 Colin O'Dell colinodell@gmail.com:
Hello everyone,
I'd like to propose an RFC to deprecate and eventually remove the "var"
keyword.My understanding is that this keyword was kept in PHP 5 for
backwards-compatibility with PHP 4. However, it's been 9 years since PHP 4
was discontinued, so I'd like to bring this topic up for review.Usage of "var" doesn't seem to be as widespread recently. I've done a quick
search of several major projects and libraries and found that only a couple
are using it. I personally haven't seen it used in any PHP 5.3+ project
I've worked on in recent memory.Because "var" simply acts as an alias for "public", removing it should not
cause any loss of functionality. Yes, it's a BC break, but developers can
easily replace it with "public" to maintain the same functionality.PHP 7 deprecated PHP 4 style constructors in favor of the PHP 5
__construct() method. I'd like to propose doing the same for the "var"
keyword - deprecate it in PHP 7.1 and remove it in a future version (7.2 or
8.0?)I'd appreciate any thoughts or feedback you may have, especially if you
have any objections to me creating an RFC for this proposal.Best regards,
Colin O'Dell
I'm +1 on this for all the reasons mentioned above. There is plenty of
time for people to update and, additionally, an automated patch script
could be provided along with the RFC.
Thank your for taking the time discuss on this mailing list.
Márcio Almada.
-1
I would prefer not to break source compatibility without a real reason.
Thanks. Dmitry.