[RFC Proposal] var keyword deprecation/removal

Sebastian Bergmann

10 years ago

On 02/18/2016 02:10 PM, Colin O'Dell wrote:

> I'd like to propose an RFC to deprecate and eventually remove the "var"
> keyword.

+1

Jakub Kubíček

10 years ago

-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

On 02/18/2016 02:10 PM, Colin O'Dell wrote:

> I'd like to propose an RFC to deprecate and eventually remove the "var"
> keyword.

+1

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Walter Parker

10 years ago

On Thu, Feb 18, 2016 at 11:30 AM, Sebastian Bergmann <sebastian@php.net>
wrote:

> On 02/18/2016 02:10 PM, Colin O'Dell wrote:
>
>> I'd like to propose an RFC to deprecate and eventually remove the "var"
>> keyword.
>>
>
>  +1
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

Colin O'Dell

10 years ago

> 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 3:25 PM Walter Parker <walterp@gmail.com> wrote:

Fleshgrinder

10 years ago

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2/18/2016 9:58 PM, Colin O'Dell 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.
>
> 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-----

Tony Marston

10 years ago

""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

Tony Marston

10 years ago

"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:
>
>> On 02/18/2016 02:10 PM, Colin O'Dell wrote:
>>
>>> I'd like to propose an RFC to deprecate and eventually remove the "var"
>>> keyword.
>>>
>>
>>  +1
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>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

Walter Parker

10 years ago

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:
>>
>> On 02/18/2016 02:10 PM, Colin O'Dell wrote:
>>>
>>> I'd like to propose an RFC to deprecate and eventually remove the "var"
>>>> keyword.
>>>>
>>>>
>>>  +1
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>> 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
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

Sara Golemon

10 years ago

> On 02/18/2016 02:10 PM, Colin O'Dell wrote:
>>
>> 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

Andrew Faulds

10 years ago

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/

Yasuo Ohgaki

10 years ago

Hi all,

On Fri, Feb 19, 2016 at 4:33 AM, Andrea Faulds <ajf@ajf.me> wrote:

>
> 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

Zeev Suraski

10 years ago

> On 18 בפבר? 2016, at 23:23, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
> Hi all,
>
>> On Fri, Feb 19, 2016 at 4:33 AM, Andrea Faulds <ajf@ajf.me> wrote:
>>
>> 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.

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

Colin O'Dell

10 years ago

>
> 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

Stas Malyshev

10 years ago

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

Colin O'Dell

10 years ago

>
> 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

Yasuo Ohgaki

10 years ago

On Fri, Feb 19, 2016 at 7:59 AM, Zeev Suraski <zeev@zend.com> wrote:

>> On 18 בפבר׳ 2016, at 23:23, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>>
>> Hi all,
>>
>>> On Fri, Feb 19, 2016 at 4:33 AM, Andrea Faulds <ajf@ajf.me> wrote:
>>>
>>> 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.
>
> 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".

I agree. There is no strong reason to remove.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Colin O'Dell

10 years ago

> 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

Thomas Punt

10 years ago

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

Colin O'Dell

10 years ago

>
> 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

Michael Wallner

10 years ago

> On 18 02 2016, at 20:33, Andrea Faulds <ajf@ajf.me> wrote:
>
> 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

Stas Malyshev

10 years ago

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

Fleshgrinder

10 years ago

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2/18/2016 10:32 PM, Stanislav Malyshev wrote:

> 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-----

Stas Malyshev

10 years ago

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

Stas Malyshev

10 years ago

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

François Laupretre

10 years ago

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

Marcio Almada

10 years ago

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.

Dmitry Stogov

10 years ago

-1

I would prefer not to break source compatibility without a real reason.

Thanks. Dmitry.

________________________________________
From: Colin O'Dell <colinodell@gmail.com>
Sent: Thursday, February 18, 2016 22:10
To: internals@lists.php.net
Subject: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

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