# [RFC Proposal] var keyword deprecation/removal - Thread: https://externals.io/message/91276 - Original archive: https://news-web.php.net/php.internals/91276 - Started by Colin O'Dell on 2016-02-18T19:10:08+00:00 - Messages: 28 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/91276.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #91276 — Colin O'Dell — 2016-02-18T19:10:08+00:00 URL: https://externals.io/message/91276#91276 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 --- ## #91278 — Sebastian Bergmann — 2016-02-18T19:30:42+00:00 URL: https://externals.io/message/91276#91278 · In reply to: #91276 > I'd like to propose an RFC to deprecate and eventually remove the "var" > keyword. +1 --- ## #91279 — kelerest123@gmail.com — 2016-02-18T19:32:47+00:00 URL: https://externals.io/message/91276#91279 -1 (minus one) Very best regards, Kubis Pandian-Fowler Od: Sebastian Bergmann Odoslané: ‎piatok‎, ‎19‎. ‎februára‎ ‎2016 ‎1‎:‎00 Komu: internals@lists.php.net > I'd like to propose an RFC to deprecate and eventually remove the "var" > keyword. +1 --- ## #91280 — Andrea Faulds — 2016-02-18T19:33:38+00:00 URL: https://externals.io/message/91276#91280 · In reply to: #91276 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/ --- ## #91283 — Walter Parker — 2016-02-18T20:24:36+00:00 URL: https://externals.io/message/91276#91283 · In reply to: #91278 On Thu, Feb 18, 2016 at 11:30 AM, Sebastian Bergmann wrote: > > > > […] > > +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 --- ## #91285 — Colin O'Dell — 2016-02-18T20:58:02+00:00 URL: https://externals.io/message/91276#91285 · In reply to: #91283 > 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 > wrote: > > > […] > 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 --- ## #91287 — Fleshgrinder — 2016-02-18T21:14:24+00:00 URL: https://externals.io/message/91276#91287 · In reply to: #91285 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > […] > > 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: > > > […] > > 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 --- ## #91288 — Yasuo Ohgaki — 2016-02-18T21:22:41+00:00 URL: https://externals.io/message/91276#91288 · In reply to: #91280 Hi all, > > Colin O'Dell wrote: > > […] > > > 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 --- ## #91289 — Stanislav Malyshev — 2016-02-18T21:32:02+00:00 URL: https://externals.io/message/91276#91289 · In reply to: #91276 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 --- ## #91290 — Fleshgrinder — 2016-02-18T21:41:17+00:00 URL: https://externals.io/message/91276#91290 · In reply to: #91289 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Hi! > > > […] > > 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 --- ## #91293 — Colin O'Dell — 2016-02-18T22:36:36+00:00 URL: https://externals.io/message/91276#91293 · In reply to: #91280 > 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 --- ## #91295 — Stanislav Malyshev — 2016-02-18T22:53:10+00:00 URL: https://externals.io/message/91276#91295 · In reply to: #91290 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 --- ## #91297 — Zeev Suraski — 2016-02-18T22:59:31+00:00 URL: https://externals.io/message/91276#91297 > > > Hi all, > > > […] > > Same opinion. > Keeping various syntax makes language more complex. I think it's a drop in the bucket compare to new features we're adding plenty of on every version. These make the language a lot more complex than var being an alias to public (not even different syntax). To me, var falls squarely in the bucket of "no strong reason to remove". Zeev --- ## #91299 — Thomas Punt — 2016-02-18T23:19:37+00:00 URL: https://externals.io/message/91276#91299 Hi! > 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? It would have to be done in 8.0, since removing it would constitute a BC break. It's worth noting that there were better reasons for deprecating PHP 4-style constructors over the simple redundancy argument. Specifically, there was confusion as to when a PHP 4-style constructor would actually be considered a constructor (see the RFC [1] for examples). With the var keyword, there's no ambiguity like this. Whilst the language purist in me would like to remove redundant things like this, I feel that it's a rather unnecessary BC break to introduce. So I'm not entirely decided on this. Thanks, Tom [1]: https://wiki.php.net/rfc/remove_php4_constructors --- ## #91300 — Colin O'Dell — 2016-02-18T23:28:14+00:00 URL: https://externals.io/message/91276#91300 · In reply to: #91297 > > I think it's a drop in the bucket compare to new features we're adding > plenty of on every version. These make the language a lot more complex > than var being an alias to public (not even different syntax). > Very true. I'm not proposing this because it's a great new feature. But has this legacy functionality outlived its original purpose? If so, maybe it's time to start phasing it out. Sure, it's a small drop in the bucket of improvements, but it's still a drop nonetheless. To me, var falls squarely in the bucket of "no strong reason to remove". > I agree 100%. But is there a strong reason to keep it forever, especially considering its decline in usage? Perhaps by targeting it for removal in 8.0 we can mitigate the impact of such a BC break while taking one small step in improving the language over time. Colin --- ## #91301 — Stanislav Malyshev — 2016-02-18T23:31:54+00:00 URL: https://externals.io/message/91276#91301 · In reply to: #91300 Hi! > But is there a strong reason to keep it forever, especially considering its Yes. It's the same reason - "no reason to remove". When we have action which on one hand has no tangible benefit and on the other hand has tangible harm, we should not do it. > decline in usage? Perhaps by targeting it for removal in 8.0 we can > mitigate the impact of such a BC break while taking one small step in > improving the language over time. By the time of 8.0 nothing would be different from today. 8.0 is not some magic number by which old code ceases to exist. -- Stas Malyshev smalyshev@gmail.com --- ## #91303 — Colin O'Dell — 2016-02-18T23:38:40+00:00 URL: https://externals.io/message/91276#91303 · In reply to: #91299 > > It would have to be done in 8.0, since removing it would constitute a BC > break. > Thanks for clarifying that Tom! Makes sense to me. > It's worth noting that there were better reasons for deprecating PHP > 4-style constructors over the simple redundancy argument. Specifically, > there was confusion as to when a PHP 4-style constructor would actually be > considered a constructor (see the RFC [1] for examples). With the var > keyword, there's no ambiguity like this. > That's a fair point. I only included that example to highlight the trend of using the PHP 5 style features over PHP 4. You're right though, there's no reason "var" might be misconstrued as something else. > Whilst the language purist in me would like to remove redundant things > like this, I feel that it's a rather unnecessary BC break to introduce. So > I'm not entirely decided on this. > I'm not 100% convinced on this either. I just thought the idea had enough merit to warrant a discussion :) Colin --- ## #91304 — Colin O'Dell — 2016-02-18T23:47:10+00:00 URL: https://externals.io/message/91276#91304 · In reply to: #91301 > > By the time of 8.0 nothing would be different from today. 8.0 is not > some magic number by which old code ceases to exist. > The usage of "var" may continue to decline as folks increasingly adopt the newer visibility keywords. Perhaps it's too early to make this decision and this discussion needs to be postponed for some time? I'm okay with that. But if/when the decision is made to remove it, doing so in a major release with ample warning seems to be the right approach, and 8.0 seems far enough way to be a potential candidate. I truly appreciate your thoughts and feedback. Thank you! Colin --- ## #91310 — francois@php.net — 2016-02-19T00:50:59+00:00 URL: https://externals.io/message/91276#91310 · In reply to: #91276 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 --- ## #91311 — Stas Malyshev — 2016-02-19T01:02:56+00:00 URL: https://externals.io/message/91276#91311 · In reply to: #91290 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 --- ## #91312 — Sara Golemon — 2016-02-19T02:19:36+00:00 URL: https://externals.io/message/91276#91312 · In reply to: #91278 > > > […] > 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 --- ## #91314 — Tony Marston — 2016-02-19T09:10:59+00:00 URL: https://externals.io/message/91276#91314 · In reply to: #91283 "Walter Parker" wrote in message news:CAMPTd_AHyV2d0_Saq=kPvhDZkKCMGkxAV8TNT4Hk9SdNGKCiiA@mail.gmail.com... > >On Thu, Feb 18, 2016 at 11:30 AM, Sebastian Bergmann >wrote: > > > […] >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 --- ## #91316 — Tony Marston — 2016-02-19T09:25:07+00:00 URL: https://externals.io/message/91276#91316 · In reply to: #91285 ""Colin O'Dell"" wrote in message news:CAJaRsPtqPKz9XSp6jF3gpm7hn39KDqpXCX4r5yN8HsohWo1gDg@mail.gmail.com... > > > […] > >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? > > […] > >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 --- ## #91324 — Walter Parker — 2016-02-19T18:41:48+00:00 URL: https://externals.io/message/91276#91324 · In reply to: #91314 On Fri, Feb 19, 2016 at 1:10 AM, Tony Marston wrote: > "Walter Parker" wrote in message > news:CAMPTd_AHyV2d0_Saq=kPvhDZkKCMGkxAV8TNT4Hk9SdNGKCiiA@mail.gmail.com... > > > […] > > 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 --- ## #91333 — Marcio Almada — 2016-02-19T21:27:28+00:00 URL: https://externals.io/message/91276#91333 · In reply to: #91276 Hi! 2016-02-18 15:10 GMT-04:00 Colin O'Dell : > 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. --- Next page: https://externals.io/message/91276.md?page=2